Status: brain-dump
Last-Updated: 2024-10-19
Summary
During a package lifecycle, they become dead, deprecated or obsoleted. When a package is dead (too buggy, no upstream, security issues, etc), these tend to get removed from an archive. But for deprecated or obsoleted packages these imply a shorter or longer transition into something else.
Currently we use a combination of heuristics to mark these packages, where various tools use them but not always in the same way. These heuristics are:
change the package Section field value to oldlibs (which applies not only to libs, and is thus a misnomer), but this has the problem that it requires an archive override change, and currently the Debian archive admins are not too keen on performing these changes (as these are manual) for transitional packages that might be "short-lived" (say one release cycle or so). See 1016928
change the package Priority field to optional. Has the same override caveats as with the Section field change.
- change the package synopsis to mention this is a "transitional", "dummy" (or both) package.
- change the package Description to mention the status of the package and what to replace it with or what to switch to.
- change the dependencies to pull in packages this one should be switched to, when this package is empty.
Some of tools that make use of these heuristics are:
There are two main categories of these packages:
- deprecated: These are intended to still be used, perhaps because they are depended on by by too many packages, but their use by new software is discouraged, and packagers are strongly encouraged to switch away to an alternative.
- obsolete: These no longer ship any actual content, so the packages are empty and serve to force pulling in the new packages that provide the alternatives.
Proposal
Ideally we'd have a declarative way to denote these states. These could be a matter of stopping to rely on the Section and Description heuristics, leave the Section field as is, and then add a couple of new fields for the declarative purposes, such as an Superseded-by and Obsolete pair of fields.
The following is an example of how they could be used:
Package: liboldthing-dev Section: libdevel Priority: optional Superseded-by: libnewthing-dev Depends: liboldthing1 Description: library doing something (deprecated) This is a deprecated library that should no longer be used by new packages, it has been superseded by libnewthing, please switch to use that.
Package: oldthing Section: admin Priority: optional Obsolete: yes Depends: newthing-a | newthing-b, newthing-plugin Description: empty transitional package obsoleted by something else This package can be safely removed once no other package depends on it.