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

Bug#776341: marked as done (apt: bugs/deficiencies in apt_preferences evaluation)

Your message dated Fri, 14 Aug 2015 15:44:58 +0200
with message-id <20150814154429.GA32321@debian.org>
and subject line Re: Bug#776341: apt: bugs/deficiencies in apt_preferences evaluation
has caused the Debian Bug report #776341,
regarding apt: bugs/deficiencies in apt_preferences evaluation
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
776341: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776341
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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.

--- End Message ---
--- Begin Message --- 
On Tue, Jan 27, 2015 at 03:28:37AM +0100, Christoph Anton Mitterer wrote:
> Hi.
> 
> I just saw that there is a POSIX ERE matching mode, which can be used to
> solve the above issue (the glob matching, which I knew of, alone
> wouldn't have so).
> 
> So I guess you can close this bug, but I leave it open for now, that you
> can double check, whether the observed behaviour is actually desired.
> 
> Also, I add a note to #776337, that the manpage should be improved to
> tell that multiple a=,a= and similar are not supported.
> Apart form that, one would perhaps welcome more examples about how to
> use the EREs,... e.g. describing which of the following it is:
> Pin: release /a=testing(|-updates)/
> Pin: release a=/testing(|-updates)/
> 
> And since those apparently als match e.g. FOOtesting:
> Pin: release /^a=testing(|-updates)$/
> Pin: release a=/^testing(|-updates)$/

Yep, closing. The behavior is intended.



-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
    - If you don't I might ignore you.

--- End Message ---
Reply to: