Differences between revisions 57 and 60 (spanning 3 versions)
Revision 57 as of 2019-08-23 19:27:13
Size: 17207
Editor: nodiscc
Comment: add CategoryRedundant, WIP
Revision 60 as of 2019-09-12 17:37:37
Size: 1263
Editor: nodiscc
Comment: WIP redirect section to AptConfiguration, all info moved there
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
'''TODO: cleanup, move to AptPinning or relevant pages/discussion pages''' == APT Preferences ==
Line 7: Line 7:
== APT-preferences overview ==

[[Apt|APT]] (the '''A'''dvanced '''P'''ackage '''T'''ool) is configured by several resources, including

 * [[AptConf|"configuration"]] - despite its name, APT-conf does very-low-level configuration
 * [[SecureApt|keys]]
 * [[SourcesList|sources]]

... in addition to the APT-preferences discussed below. APT-preferences can be used for various tasks; unfortunately only ''pinning'' is currently discussed below. For more detailed, authoritative information regarding

 * the Debian packaging system (of which APT-preferences is a very small part): see [[https://www.debian.org/doc/manuals/debian-reference/ch02.en.html|Chapter 2 of the Debian Manual]].
 * APT-preferences itself: see the apt_preferences(5) manpage, which you can do by running the commandline `man apt_preferences` (among others).

== APT-preferences configuration ==

Like the rest of the [[Apt|APT]] configuration resources, APT-preferences is configured by writing information to files in one of two ways:

 1. The newer, more easily extensible, preferred way: writing multiple files to a single directory. For APT-preferences, that directory is `/etc/apt/preferences.d/`
 1. The old, deprecated way: writing all APT-preferences information to a single file, `/etc/apt/preferences`

Unlike the other APT configuration resources, APT-preferences is closely tied to [[SourcesList|APT-sources]], so we will need to discuss that here also. APT-sources are similarly configured in one of two ways:

 1. The newer, more easily extensible, preferred way: writing multiple files to `/etc/apt/sources.list.d/`
 1. The old, deprecated way: writing all sources/repositories information to `/etc/apt/sources.list`
However, pinning also utilizes the concept of ''target release'', which is typically set using [[AptConf|APT-conf]] ... which is (you guessed) similarly configured in one of two ways:

 1. The newer, more easily extensible, preferred way: writing multiple files to `/etc/apt/apt.conf.d/`
 1. The old, deprecated way: writing all target-release information to `/etc/apt/conf`

Finally, the reader should understand that all of the following can be specified or overridden using various commandline, TUI, or GUI tools such as [[apt]], [[apt-get]] and [[aptitude]].

<<Anchor(Pinning)>>
== Pinning ==

<!> When pinning, '''you must ensure compatibility of packages by yourself''' since Debian does not guarantee it. Note that pinning is completely optional, and '''Debian does not encourage pinning''' without thorough consideration.

/!\ '''Seriously, don't do this.''' Doing this will [[DontBreakDebian|break Debian]] and leave you with a system that doesn't work and can't be fixed. Use [[Backports]] instead!

''Pinning'' allows you to pull particular packages from one version (e.g., ''stable'', ''testing'', ''unstable'') without running your entire system from that version. Pinning is usually (though not always) used to pull one or more packages from a later version, in order to access more up-to-date versions of packages: ''unstable'' is considered later than ''testing'' which is later than ''stable''. However, packages have dependencies which can conflict, so pinning (i.e., not pulling all your packages from one version) can cause problems. Accordingly, before you consider pinning, check to see if the version of the package that you want has been [[Backports|backported]] to the version from which you are already pulling packages.

=== /etc/apt/sources.list ===
{{{
#### testing #########
deb http://deb.debian.org/debian testing main contrib non-free
}}}
{{{
#### unstable #########
deb http://deb.debian.org/debian unstable main contrib non-free
}}}

In this example, we're pulling from ''testing'' and ''unstable''. You could, of course, modify this to pull from ''stable'' as well.

=== /etc/apt/preferences ===
The 'preferences' file is where the actual ''pinning'' takes place. Here's an example:
{{{
Package: *
Pin: release a=testing
Pin-Priority: 900
}}}
{{{
Package: *
Pin: release a=unstable
Pin-Priority: 800
}}}

'''Package''' defaults to any, as specified by the asterisk. '''Pin''' specifies the release (''testing'' and ''unstable''). '''Pin-Priority''' specifies the priority level. 'apt' defaults to something along the lines of "highest package version wins". The above restructures this priority so that packages in ''testing'' are given a higher priority.

=== Installing from unstable ===
Let's assume that we're running ''testing'' and we want to try enlightenment from ''unstable''. There are basically two methods for installing:
{{{
 # apt install enlightenment/unstable
 # apt -t unstable install enlightenment
}}}

The first will not attempt to upgrade any packages on your system, so if specific dependencies are not met, the install will fail. The second method '''will''' attempt to install/upgrade any dependencies. Of course, given the above example, 'apt' will ask you before proceeding.

=== Notes from JoshuaRodman ===

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
}}}

'''Note that a priority above 1000 will allow even downgrades no matter the version of the prioritary package. This means that you can use priority 1001 for a stable source if you want to downgrade to the stable versions of the packages you have installed (let's say from testing) on the system.''' this is not recommended unless the number of changes are minimal

Installing packages with {{{apt install packagename/unstable}}} and {{{apt install -t unstable packagename}}} will both still work, but unstable packages will only be installed by these commands.

=== Notes from ZugSchlus ===
==== 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 ====

-->[[DebianBug:685215|Here]] is what one user thinks it should be.

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.
 * In case of several packages with the same version, apt picks the one from the distro listed first in sources.list

==== 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 explicit pinning, experimental will be automatically pinned to priority 1. This is because experimental's Release file contains `NotAutomatic: yes`.
 * 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.
   * 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.
===== Example 3 =====
From Mihamina rakotomandimby

Suppose you have a personnal repository where you have a personnal version of Postfix. You want Apt to prefer you version over official ones.

You may set preferences by Origin

{{{
Package: *
Pin: origin www.rktmb.org
Pin-Priority: 610

Package: *
Pin: origin ftp.fr.debian.org
Pin-Priority: 600
}}}

==== 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. The number on the right of the version number displays the actual pin priority being placed on the package.

=== Notes from Ryan B. ===
If you're wondering what the options are for release file preferences, based on this link:
http://www.debian.org/doc/manuals/repository-howto/repository-howto

we find:

Archive: ''archive''

Component: ''component''

Origin: ''Your Company''

Label: ''Your Company Debian repository''

Architecture: ''architecture''

Thus, the line: "Pin: release a=testing" would find archive values in the release file named "testing".

=== Notes from GeorgiosZarkadas ===

I found that using a higher than 500 value to pin testing/unstable resulted in apt upgrade wanting to upgrade all packages with a newer version to testing/unstable even while I had stable pinned with a higher value than testing/unstable.

After, querying the outcome of apt-cache policy <some-package> for a number of the packages that apt upgrade considered that they should be upgraded, I concluded that if there are multiple versions with candidates pinned to 500 or higher, then pinning is considered '''after''' the version number. Thus the highest version with the highest pin weight among the candidates of that (and only that) version is selected.

For example (having stable pinned to 700, testing to 650 and unstable to 600):
{{{
root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο: 1.7.28.5
  Πίνακας Έκδοσης:
     1.7.28.5 0
        650 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        600 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        700 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages
}}}

Since my aim for using multiple sources and pinning was to be able to occasionally install a package from testing or unstable and not upgrade all my packages, pinning testing / unstable to values equal or greater than 500 is clearly an insuitable method for the stated cause.

However, I found that using a value less than 500 for testing/unstable has the desired effect. For example (removed stable pin and set testing to 450 and unstable to 400):
 
{{{
root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο: 1.7.28.3+squeeze1
  Πίνακας Έκδοσης:
     1.7.28.5 0
        450 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        400 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        500 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages
}}}

=== Notes from Dmitriy Matrosov ===

I think, that Georgios Zarkadas's conclusion ([[AptPreferences#Notes_from_GeorgiosZarkadas|from previous notes]]) about "pinning considered by apt after version number":

{{{
I concluded that if there are multiple versions with candidates pinned to 500 or higher, then pinning is considered '''after''' the version number.
}}}

is wrong. Let's look once again at example he posted:

{{{
root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο: 1.7.28.5
  Πίνακας Έκδοσης:
     1.7.28.5 0
        650 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        600 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        700 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages
}}}

First, apt tries to upgrade from stable (squeeze/main) since stable has highest priority (700), but it sees, that installed package is newer:

{{{
sgf@shilvana:~$ dpkg --compare-versions 1.7.28.3 lt '1.7.28.3+squeeze1' ; echo $?
0
}}}

and priority 700 is not enough to downgrade. So, it looks further for candidate version. And now apt tries to upgrade from testing (wheezy/main) and sees, that version from testing is newer:

{{{
sgf@shilvana:~$ dpkg --compare-versions '1.7.28.3+squeeze1' lt 1.7.28.5 ; echo $?
0
}}}

And hence, this version (from testing) become a candidate.

So, in order to upgrade from stable (as Georgios Zarkadas wants), he must have this package at version <= than one found in stable.
'''See [[AptConfiguration#apt_preferences_.28APT_pinning.29|AptConfiguration]]'''

Translation(s): English - Italiano - Español- Русский - 简体中文


APT Preferences

See AptConfiguration

References


CategoryPackageManagement | CategoryRedundant: merge with AptConf -> AptConfiguration