Size: 213
Comment:
|
Size: 5975
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 2: | Line 2: |
{{{ man 5 apt_preferences | = AptPreferences = {{{/etc/apt/preferences}}} is a file in {{{/etc/apt}}}, the AptDirectory. == Available Docs == * {{{man 5 apt_preferences}}} * [http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html Apt-Howto] (Section 3.10) and AptPinning. == Disclaimer == This page has been written by ZugSchlus, who not even remotely grasps the concept of pinning. So, please take the words "probably", "needs to be verified" and similiar wordings literally, and document your findings (may they be "this page is right" or "this page is wrong", optionally "this page is wrong because") here. == Description of Package Selection Process == TODO: This needs to be verified * Ignore packages that don't meet version criteria * Ignore packages lower versioned than current, unless their priority is > 1000 * Install highest priority remaining package * In case of priority tie, take pinned package. * This step should probably be skipped if the pin doesn't match anything * In case of no pinned package, take highest version. == Examples of {{{/etc/apt/preferences}}} file == === Example 1 === {{{ Package: * Pin: release o=Debian,a=testing Pin-Priority: 900 }}} {{{ Package: * Pin: release o=Debian,a=unstable Pin-Priority: 300 }}} {{{ Package: * Pin: release o=Debian Pin-Priority: -1 |
Line 5: | Line 40: |
See also [http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html Apt-Howto] (Section 3.10) and AptPinning. -- StephenHargrove |
Missing: Documentation what this preferences file does. ZugSchlus tries to explain: * All packages from a distribution called testing are pinned to 900 * All packages from a distribution called unstable are pinned to 300 * All other packages from Debian are pinned at -1 and thus never installed. Problem: This pin behaves differently depending on which target release is set in other parts of apt configuration. Hence, this example cannot really be documented without adding more information. A non-pinned package being part of the target release has default priority 990, while other non-pinned packages have a default priority of 500. === Example 2 === Objective: On an unstable system, pull dpatch from experimental. A possible (and not completely correct) solution: * Have both unstable and experimental in {{{sources.list}}} * In Absence of a preferences file, experimental will be automatically be pinned to priority 1. Question: Is this hardcoded, or configured somewhere on the target system, or on the Mirror? * Pin the wanted packages to a value x with 100<x<500:{{{ Package: dpatch Pin: release o=Debian,a=experimental Pin-Priority: 450 }}} * A value > 500 will always select a package from experimental, even preventing a higher numbered unstable package from being installed, and selecting "no package at all" ahead of all available packages if the distribution not containing that package is pinned higher. * Unfortunately, the Package field understands neither wildcards nor regular expressions. You need one pin stanza per package. * Pinning the package to 450 will probably not automatically update to the experimental package, but it will probably track the package in experimental as long as it stays higher-versioend than the one in unstable. == Debugging == {{{apt-cache policy package}}} gives information about the selection process. Unfortunately, it is not widely known what the output means. The following is a try to interpret: {{{ $ apt-cache policy exim4-daemon-light exim4-daemon-light Installed: 4.50-1 Candidate: 4.50-1 Package Pin: (not found) Version Table: 4.50-4 555 500 http://mirror sid/main Packages *** 4.50-1 555 100 /var/lib/dpkg/status 4.44-2 555 500 http://mirror sarge/main Packages }}} The priority of each version/location is the number at the left of it. In this case, 500, 100, and 500. It is unclear what the number at the right of the version number means. Some people believe that it is just the last period that was specified for this package in {{{/etc/apt/preferences}}} for that package, while others said it is the actual pin priority being placed on the package. TODO: This section was written after taking a lot of more or less educated guesses. Would somebody with real knowledge of apt please verify? == Credits == * StephenHargrove, who probably did the initial version of this page (if ZugSchlus interpreted the revision history correctly) * ZugSchlus, who tried to add some explanations and more examples * with help from Adeodato Simó and Paul Hampson on {{{debian-devel@l.d.o}}} ------- (Integrate, remove, move, whatever. Just trying to offer another choice.) Personally, I found the common configuration of a higher priority Testing pin and a lower priority Unstable pin to be problematic. At times, testing packages will depend upon other packages which are not currently in testing (perhaps representing a small glitch in testing) which causes packages to be automatically pulled in from unstable. In the period of testing prior to stabilization for the Woody release, this caused me to end up with over 100 unstable packages installed without even realizing it. As a a result, I use a more conservative "only if I say so" approach to a mixed distribution, with a Pin file like this: {{{ Package: * Pin: release a=testing Pin-Priority: 900 }}} {{{ Package: * Pin: release o=Debian Pin-Priority: -10 }}} Thus all debian packages are defaulted to priority -10, while testing receives a 900 point bonus. This invokes the behaviors: From {{{apt_preferences(5)}}}{{{ 500 < P <=990 : causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent [...] P < 0 : prevents the version from being installed }}} Installing packages with {{{apt-get install packagename/unstable}}} and {{{apt-get install -t unstable packagename}}} will both still work, but unstable packages will only be installed by these commands. -- JoshuaRodman |
AptPreferences
/etc/apt/preferences is a file in /etc/apt, the ?AptDirectory.
Available Docs
man 5 apt_preferences
[http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html Apt-Howto] (Section 3.10) and AptPinning.
Disclaimer
This page has been written by ZugSchlus, who not even remotely grasps the concept of pinning. So, please take the words "probably", "needs to be verified" and similiar wordings literally, and document your findings (may they be "this page is right" or "this page is wrong", optionally "this page is wrong because") here.
Description of Package Selection Process
TODO: This needs to be verified
- Ignore packages that don't meet version criteria
Ignore packages lower versioned than current, unless their priority is > 1000
- Install highest priority remaining package
- In case of priority tie, take pinned package.
- This step should probably be skipped if the pin doesn't match anything
- In case of no pinned package, take highest version.
Examples of {{{/etc/apt/preferences}}} file
Example 1
Package: * Pin: release o=Debian,a=testing Pin-Priority: 900
Package: * Pin: release o=Debian,a=unstable Pin-Priority: 300
Package: * Pin: release o=Debian Pin-Priority: -1
Missing: Documentation what this preferences file does.
ZugSchlus tries to explain:
- All packages from a distribution called testing are pinned to 900
- All packages from a distribution called unstable are pinned to 300
- All other packages from Debian are pinned at -1 and thus never installed.
Problem: This pin behaves differently depending on which target release is set in other parts of apt configuration. Hence, this example cannot really be documented without adding more information. A non-pinned package being part of the target release has default priority 990, while other non-pinned packages have a default priority of 500.
Example 2
Objective: On an unstable system, pull dpatch from experimental.
A possible (and not completely correct) solution:
Have both unstable and experimental in sources.list
- In Absence of a preferences file, experimental will be automatically be pinned to priority 1. Question: Is this hardcoded, or configured somewhere on the target system, or on the Mirror?
Pin the wanted packages to a value x with 100<x<500:
Package: dpatch Pin: release o=Debian,a=experimental Pin-Priority: 450
A value > 500 will always select a package from experimental, even preventing a higher numbered unstable package from being installed, and selecting "no package at all" ahead of all available packages if the distribution not containing that package is pinned higher.
- Unfortunately, the Package field understands neither wildcards nor regular expressions. You need one pin stanza per package.
- Pinning the package to 450 will probably not automatically update to the experimental package, but it will probably track the package in experimental as long as it stays higher-versioend than the one in unstable.
Debugging
apt-cache policy package gives information about the selection process. Unfortunately, it is not widely known what the output means. The following is a try to interpret:
$ apt-cache policy exim4-daemon-light exim4-daemon-light Installed: 4.50-1 Candidate: 4.50-1 Package Pin: (not found) Version Table: 4.50-4 555 500 http://mirror sid/main Packages *** 4.50-1 555 100 /var/lib/dpkg/status 4.44-2 555 500 http://mirror sarge/main Packages
The priority of each version/location is the number at the left of it. In this case, 500, 100, and 500. It is unclear what the number at the right of the version number means. Some people believe that it is just the last period that was specified for this package in /etc/apt/preferences for that package, while others said it is the actual pin priority being placed on the package.
TODO: This section was written after taking a lot of more or less educated guesses. Would somebody with real knowledge of apt please verify?
Credits
StephenHargrove, who probably did the initial version of this page (if ZugSchlus interpreted the revision history correctly)
ZugSchlus, who tried to add some explanations and more examples
with help from Adeodato Simó and Paul Hampson on debian-devel@l.d.o
(Integrate, remove, move, whatever. Just trying to offer another choice.)
Personally, I found the common configuration of a higher priority Testing pin and a lower priority Unstable pin to be problematic. At times, testing packages will depend upon other packages which are not currently in testing (perhaps representing a small glitch in testing) which causes packages to be automatically pulled in from unstable. In the period of testing prior to stabilization for the Woody release, this caused me to end up with over 100 unstable packages installed without even realizing it.
As a a result, I use a more conservative "only if I say so" approach to a mixed distribution, with a Pin file like this:
Package: * Pin: release a=testing Pin-Priority: 900
Package: * Pin: release o=Debian Pin-Priority: -10
Thus all debian packages are defaulted to priority -10, while testing receives a 900 point bonus. This invokes the behaviors:
From apt_preferences(5)
500 < P <=990 : causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent [...] P < 0 : prevents the version from being installed
Installing packages with apt-get install packagename/unstable and apt-get install -t unstable packagename will both still work, but unstable packages will only be installed by these commands.
-- JoshuaRodman