PackageMaintainednessPresentation
Launchpad Entry: package-supportedness-ui
Contributors: MichaelVogt, MatthewPaulThomas
Packages affected: apt, synaptic, gnome-app-install
Summary
How to represent the security/critical fixes support level of the various applications in ubuntu.
Release note
None necessary.
Rationale
Canonical maintains packages in the Ubuntu archive for different periods, and “maintains” means different things depending on whether the package is Free Software (as currently represented by Main vs. Restricted). Ubuntu’s package management tools do not make it clear how long each package is maintained for, and what this means.
Scope
Canonical maintains:
- packages that are part of Ubuntu Server for five years in LTS releases, and three years in non-LTS releases.
- other packages in the Main repository for three years in LTS releases, and 18 months in non-LTS releases.
“Maintains”, in this sense, means:
- If Canonical is able to modify and redistribute modified versions of the package (currently represented by the package being in “Main”), it provides fixes for security problems and other critical defects.
- If Canonical does not have the source code and permission to redistribute modified versions (currently represented by the package being in “restricted”), it seeks fixes from the vendor for security problems and other critical defects.
“Maintains” should not be confused with “supports”, which is about paid assistance from Canonical’s support team or from other support providers. It is possible that we may advertise supportedness of software in package management tools in future, but for now we will not.
Use cases
- Some server administrators want to be sure that all packages they install are maintained by Canonical. These admins use apt-get or aptitude, not Synaptic or Add/Remove Programs.
We have no other known use cases. However, we currently present maintainedness ambiguously in Synaptic and Add/Remove Programs, and we should present it unambiguously.
Design
Add/Remove Applications
In the “Show” menu, “Supported applications” should be renamed to “Canonical-maintained Applications”...
Synaptic
apt-get
apt / aptitude
“aptitude show package-name” and “apt-cache show package-name” should include information about how long Canonical will provide critical updates for the package. For example:
> aptitude show fontforge Package: fontforge State: not installed Version: 0.0.20071110-1build2 Priority: optional Section: x11 Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com> Canonical provides critical updates until: 2011-04-28 Uncompressed Size: 12.3M Depends:...
In addition to the "canonical supports this package for now long" information there is a additional dimension to the support. When the spec gets implemented the support status can no longer we distinguished between main and universe because there will only be a single archive. The support status then depends on what flavor of ubuntu is installed (ubuntu-studio, regular ubuntu etc). This needs to be represented in the UI as well.
Implementation
Package infrastructure
The implementation should be done with debtags. We add a debtag "Facet" that does not use the word "support", and add tags like "canonical-5years" or "canonical-3years".
For the support status based on the installed version of ubuntu we add tags that match the meta-packages, e.g. "part-of::ubuntu-desktop", "part-of::ubuntu-studio-desktop" etc. This way the packaging tools can check for the installed meta packages and then figure out the support status based on that information. This way it can rank packages that are part of this group higher in e.g. searches.
The synaptic lp:~mvo/synaptic/ept branch has some support for debtags and with "debtags::getItemsHavingTag()" and "getItemsHavingTags()" it should straightforward to implement the required views and emblems. The tag information needs to be added to the debtags package, this includes the new facet in the vocabulary and the new tags.
For the python based applications the emblems can be displayed based on the information that is available via the python-debian debtags interface.
For the CLI tools we should modify apt-ftparchive so that the support time is added to the package record by apt-ftparchive
http://www.ubuntu.com/community/ubuntustory/components should be updated to refer consistently to "maintenance" rather than "support".
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release.
This need not be added or completed until the specification is nearing beta.
Unresolved issues
- We need to get the list of supported packages for the various support levels for each release. It needs to be discussed if this should be done via germinate or via a different method.
- Where will “critical” be defined?