[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#776341: apt: bugs/deficiencies in apt_preferences evaluation



Source: apt
Version: 1.0.9.6
Severity: normal


Hi.

I recently noted a "bug" in my own apt_preference configuration... what I
do is roughly the following:
I have a Debian installed as e.g. stable, but wish to take certain packages
from other suites, so I enable these suites in sources.list, e.g.
  deb http://debian.mirror.lrz.de/debian/ stable main contrib non-free
  deb http://debian.mirror.lrz.de/debian/ stable-updates main contrib non-free
  
  deb http://debian.mirror.lrz.de/debian/ testing main contrib non-free
  deb http://debian.mirror.lrz.de/debian/ testing-updates main contrib non-free
  deb http://debian.mirror.lrz.de/debian/ testing-proposed-updates main contrib non-free
  
  deb http://debian.mirror.lrz.de/debian/ unstable main contrib non-free
"disable" all packages from the non-stable suites via apt_preferences, e.g.
via something like:
  Package: *
  Pin: release o=Debian,a=testing
  Pin-Priority: 1
and selectively enable those packages from other suites I want, e.g. via:
  Package: foobar
  Pin: release o=Debian,a=testing
  Pin-Priority: 500

Worked fine, till I've noted yesterday, that sudo was going to be upgraded,
which I haven't pinned. So I looked it up and found that testing-updates and
testing-proposed-updates use their own names as Suite: ... okay, my bad, I
needed to add disabling rules for these as well, e.g.
  Package: *
  Pin: release o=Debian,a=testing-updates
  Pin-Priority: 1
and so on.


Then I noticed that my pinning of single packages would of course suffer from
the same problem, i.e. when I pin a=testing, and a newer version is in a=testing-*
it wouldn't be taken.
The same when I want to do something like "take package foo from testing|unstable,
whichever is newer" (of course this doesn't make that much sense given how
testing/unstable works, at least in Debian).

So I tried for sudo something like:
  Package: sudo
  Pin: release o=Debian,a=testing,a=testing-updates,a=unstable
  Pin-Priority: 1
which seemed to work at first, but then I've noted that apparently apt takes simply
only the last a=... IOW, multiple a=,a=,... is not like OR (which should be documented
btw.)
Simply revert the order, e.g. a=unstable,a=testing,... and you'll see that it will NOT
take the highest version from all ORed suites.



Next, and this is where IMHO the actual bug/deficiencie lies, I tried:
  Package: sudo
  Pin: release o=Debian,a=testing
  Pin-Priority: 1
  Package: sudo
  Pin: release o=Debian,a=unstable
  Pin-Priority: 1
which showed, that this seems to work like a stop-after-first-match.
IOW, it does the testing match, but doesn't pin unstable.
If one disables testing from sources.list, it would even not find a pin
at all (apt-cache policy telling: "Package pin: (not found)").

So in the end, the whole idea of selectively pinning a package for one specific
suite works only for ONE suite.
Which is apparently quite bad, given that testing/testing-updates/testing-proposed-updates
are handled as different suites.
The same when you add Debian Backports to the game...


Cheers,
Chris.


Reply to: