/etc/apt/preferences
moin, moin,
playing with /etc/apt/preferences and I wanted to check if I understand how
to properly wield this really cool capability :).
First, I'm trying to track specific dists, but be able to grab packages from
another dist. I want to be able to automagically get updates from the more
unstable dist or not depending on the package, machine, phase of the moon,
etc. :).
# cat /etc/apt/preferences
Package: *
Pin: release a=stable
Pin-Priority: 900
Package: *
Pin: release a=testing
Pin-Priority: 70
Package: *
Pin: release a=unstable
Pin-Priority: 60
This seems to work really well. It'll grab updates for stable ( I'm
cheating, I've got apt 0.5.3 from testing, but might be still running stable
). It doesn't grab updates for testing or unstable, even for packages whose
current installed version stems from them because both of those are pinned
below 100, e.g. the priority of the installed package. I can still "apt-get
install <package>/testing" and get a newer package from testing if one is
available.
If I add zeroes to the priorities of testing and unstable, e.g. 700 and 600
respectively, then stable gets priority, but if a package is out of testing
and there is a new version in testing it will want to update to the newer
version from testing. Same for unstable. "apt-get install <package>/testing"
behaves the same as above. Packages that aren't already from testing or
unstable will continue to follow the track for stable. This includes
packages that are grabbed by the install due to dependencies, provided the
version in the preferred dist fulfill the requirements, e.g. if package a
depends on package b of a revision only available in testing and package b
depends on package c, but the revision in stable fulfills the requirement,
then a/testing, b/testing and c/stable will be installed. This is just so
majorly cool! :)
If I switch stable and testing, then a dist-upgrade will bring everything
current with testing. The behavior listed in the previous paragraph
continues, but now everything defaults to testing.
I do notice, however, that when one uses * for a release, but specifically
pins a package to below 100, then it will still be upgraded. I presume what
happens is that the specific release just becomes another one of the
possibilities, so the greater possibility wins. OTOH, trying globbing on
Package doesn't seem to be working, e.g. "Package: a*" seems to be matching
packages that don't start with 'a'. Hmm, "Package: <package>" with a
Pin-Priority of 900 for stable was sufficient to call for a downgrade from
testing. That should only happen if the package has a Pin-Priority over
1000. None of the Pin-Priorities in my /etc/apt/preferences file at the time
were over 900.
Is there a way to specify "installed" as the release archive? That way I
could give "Package: <package>" from "Pin: release a=installed" a
Pin-Priority of 1001 or something.
OK, got the matching everything on "Package: a*" figured out. If a dist
is left out that is in sources.list, then if it's more recent it seems to
become default. That must be the "and 500 are all the default package files"
part of the documentation :) ( man apt_preferences for those interested :).
I think that should be more clearly explained in the docs, which is why I
leave the questions from before I figured it out in this email :).
Now, got testing pinned back at 30, so no updates from there, but if I
do pin something via globbing at a higher priority it still won't match.
Conflict because it now has two pin priorities for the same package from
one dist? Maybe, but taking out the pin for the release itself and then
using <char>* matching also doesn't work. Tried several different chars
and I think at least gnupg has nothing depending on it, so doubt it was to
fulfill a dependency for something else. Matching the package explicitly
also doesn't work.
This might all be the intended behavior. I don't know, which is why I'm
asking :).
BTW, are comments allowed at all? //, " and # all cause an error:
E: Invalid record in the preferences file, no Package header
/* */ get ignored, e.g. no error, but they don't comment anything out
either.
Based on /usr/share/doc/apt/examples/apt.conf I'd think // and /* */ should
function as comments.
ciao,
der.hans
--
# der.hans@LuftHans.com home.pages.de/~lufthans/ www.DevelopOnline.com
# "... the social skills of a cow on acid." - der.hans
Reply to: