I'd like to propose a new policy view.
This is the current output of "apt-cache policy" (modified from [22]):
-- apt-cache policy <package-name> --
<package-name>:
Installed: <installed-version>
Candidate: <version-installed-when-doing-apt-get-upgrade>
Package-Pin: <version-of-Pin-in-etc-apt-preferences>
Version table:
*** <version-available-in-repos-1&2> <more-specific-priority>
<priority-of-source-1> <repository-1>
<priority-of-source-2> <repository-2>
<other-version-available-in-repos-3&4> <more-specific-priority>
<priority-of-source-3> <repository-3>
<priority-of-source-4> <repository-4>
-- end apt-cache policy package-name --
The breakdown of the three dubious fields is this:
<version-of-Pin-in-etc-apt-preferences>
This field marks the version that corresponds to the first-matched more
specific rule (e.g. with "Package: <package-name>" and/or "Pin: version
3*"). This version has the priority <more-specific-priority>.
IMHO, this field is completely redundant.
<more-specific-priority>
This field is the Pin-Priority that corresponds with the first-matched
more specific form ("Package: <package-name>" and/or "Pin: version 3*").
This field too, IMHO, is a design flaw, is redundant and should be removed.
<priority-of-source-X>
This field corresponds to the Pin-Priority of the whole
release/archive/origin set with wildcard "Package: *" (called a general
form in the manual).
I kindly challenge your views on two IMHOs above.
I propose a a new "apt-cache policy" output:
-- new apt-cache policy <package-name> --
<package-name>:
Installed: <installed-version>
Candidate: <version-installed-when-doing-apt-get-upgrade>
[Package-Pin: general|specific]
Version table:
*** <version-available-in-repos-1&2>
<priority-of-source-1> <repository-1>
<priority-of-source-2> <repository-2>
<other-version-available-in-repos-3&4>
<priority-of-source-3> <repository-3>
<priority-of-source-4> <repository-4>
-- end new apt-cache policy <package-name> --
Package-Pin property is marked optional, and it only tells whether the
package is being pinned at all and whether the pin is only a general form
(release-wide) pin, or a more specific pin for that package/version is in
effect.
The breakdown of the dubious field here is:
<priority-of-source-X>
The cumulative all-things-considered priority of package <package-name>
(set with specific form pin stanza), version
<version-available-in-repos-Y> (set with specific form pin stanza) from
<repository-Z> (set with general form pin stanza or APT::Default-Release).
Thus, a single priority is set for each triplet <package, version, source>
(which is supposed to be but absolutely not the case currently, and
is instead more like what cupt does). Among the highest
<priority-of-source-X> the one with the highest
<version-available-in-repos-Y> wins and becomes the Candidate.
As presented in the follow-up algorithm pseudo code, this is easily achieved
if the policy regarding rules being first-match is reversed and
instead the last general rule wins and is overwritten by the last relevant
specific rule (if such exists).
Everything else regarding priorities and policy remains as currently
documented.
Backward-compatibility notice & Disclaimer
------------------------------------------
AFAIK, current implementation didn't allow for complicated apt_preferences
setups that could have break under this "new" policy.
I don't know how else these priorities are used internally throughout the apt
suite, and who else relies on "apt-cache policy" output being exactly as is.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
