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 -- # [EMAIL PROTECTED] home.pages.de/~lufthans/ www.DevelopOnline.com # "... the social skills of a cow on acid." - der.hans
