Perhaps for open discussion: I would think the proper definition for "obsolete package" would be: A package that, under the current apt_preference policies, would no longer be installed (in that version) and/or no longer receive updates.
If there's only one suite/repo, than this is of course equal to "cannot be longer downloaded", which however is of little use for an admin. Under multi-suite/repo configurations, with package pinning, complex apt_preference configurations, etc. this definition would already match for my lcms1 example: # apt-cache policy liblcms-utils liblcms-utils: Installed: 1.19.dfsg2-1.5+b2 Candidate: 1.19.dfsg2-1.5+b2 Version table: *** 1.19.dfsg2-1.5+b2 0 100 /var/lib/dpkg/status 1.19.dfsg-1.2 0 1 http://ftp.de.debian.org/debian/ stable/main amd64 Packages in contrast to: # apt-cache policy aptitude aptitude: Installed: 0.6.11-1 Candidate: 0.6.11-1 Version table: *** 0.6.11-1 0 500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status 0.6.8.2-1 0 1 http://ftp.de.debian.org/debian/ stable/main amd64 Packages Then clearly, liblcms-utils 1.19.dfsg2-1.5+b2 is only available locally (no "500 http://ftp.de.debian.org/debian/ unstable/main amd64" line for it) and 1.19.dfsg-1.2 isn't the candidate version either. => liblcms-utils won't receive any more updates (in the current config) and should therefore be considered obsolete. The package aptitude 0.6.11-1 however is not obsolete, the candidate version is still available non-locally. I think the problem is also, that obsoleteness is kinda defined for a package only, while it should be defined for package+version combination. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature