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
_______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
