pinning a specific package does not work

[Rolf Leggewie]

Binary package hint: apt

"Package: *" in /etc/apt/preferences works for pinning as expected. "Package: nano" should work, but currently does not. This is already known in Debian (c.f. http://bugs.debian.org/317186). Setting this ticket to confirmed.

Specifying only part of the package name is currently unsupported. There is an RFE ticket in Debian to include support for this: http://bugs.debian.org/121132 which is tracked in LP bug 399474

[Julian Andres Klode (juliank)]

Such a bug does not exist, and to my knowledge never existed. As we can
see in the following example, the pin of 9999 is respected correctly.

(natty)root@jak-thinkpad:/home/jak# cat /etc/apt/preferences.d/sudo
Package: sudo
Pin: version 1.7.4p4-5ubuntu7
Pin-Priority: 9999
(natty)root@jak-thinkpad:/home/jak# apt-cache policy sudo
sudo:
  Installed: 1.7.4p4-5ubuntu6
  Candidate: 1.7.4p4-5ubuntu7
  Package pin: 1.7.4p4-5ubuntu7
  Version table:
     1.7.4p4-5ubuntu7 9999
        500 http://localhost/ubuntu/ natty/main amd64 Packages
 *** 1.7.4p4-5ubuntu6 9999
        100 /var/lib/dpkg/status

[Rolf Leggewie (r0lf)]

Julian, thank you for your work for Ubuntu and Debian. But may I suggest you are a bit more careful marking invalid when there are at least a good half dozen people telling you here and in the Debian BTS that there is a problem? It's always safe to ask for more feedback before pulling the trigger.

This is of course a very valid bug. Here is the proof. I say that as somebody who is always struggling to get pinning right, though. It's a great tool but not always user-friendly and idiot-proof ;-) If I am not mistaken, you are struggling with pinning yourself ;-) Your example is actually not really showing anything. 1.7.4p4-5ubuntu7 would have been preferred and installed over 1.7.4p4-5ubuntu6 anyway without any pinning.

$ cat /etc/apt/preferences.d/canonical-partner
Package: acroread
Pin: origin archive.canonical.com
Pin-Priority: 10

$ apt-cache policy acroread
acroread:
  Installed: 9.3.3-0.0
  Candidate: 9.4.2-0lucid1
  Package pin: 9.4.2-0lucid1
  Version table:
     9.4.2-0lucid1 10
        500 http://archive.canonical.com/ubuntu/ lucid/partner Packages
 *** 9.3.3-0.0 10
        200 http://private-repo/deb-private/ ./ Packages
        100 /var/lib/dpkg/status
$ sudo sed -i s/acroread/\*/ /etc/apt/preferences.d/canonical-partner
$ cat /etc/apt/preferences.d/canonical-partner
Package: *
Pin: origin archive.canonical.com
Pin-Priority: 10

$ apt-cache policy acroread
acroread:
  Installed: 9.3.3-0.0
  Candidate: 9.3.3-0.0
  Version table:
     9.4.2-0lucid1 0
         10 http://archive.canonical.com/ubuntu/ lucid/partner Packages
 *** 9.3.3-0.0 0
        200 http://private-repo/deb-private/ ./ Packages
        100 /var/lib/dpkg/status
$ sudo rm /etc/apt/preferences.d/canonical-partner
$ apt-cache policy acroread
acroread:
  Installed: 9.3.3-0.0
  Candidate: 9.4.2-0lucid1
  Version table:
     9.4.2-0lucid1 0
        500 http://archive.canonical.com/ubuntu/ lucid/partner Packages
 *** 9.3.3-0.0 0
        200 http://private-repo/deb-private/ ./ Packages
        100 /var/lib/dpkg/status

[Rolf Leggewie (r0lf)]

It's very much possible that I am misinterpreting the output of "apt-cache policy". As others have pointed out in the Debian BTS it is not always clear what the numbers in different positions mean (" *** 9.3.3-0.0 10", for example, why 10 and 0 for the other two times later on?). Be that as it may, the important thing is whether the package is pinned. And that is not the case unless using *, the package with the higher version number from the partner repo will get installed. And that is what this bug report is about. QED

[Rolf Leggewie (r0lf)]

hm, there seem to be a lot of things amiss. For one thing, aptitude does not seem to honor /etc/apt/preferences.d/* whereas apt-cache does: bug 766238

[Julian Andres Klode (juliank)]

Short explanation:

  - The numbers displayed before URLs are calculated from the Package: * pins
  - The number after the versions is the pin given using a specific pin

(a)
  Package pin: 9.4.2-0lucid1
  Version table:
     9.4.2-0lucid1 10
        500 http://archive.canonical.com/ubuntu/ lucid/partner Packages

Means that acroread version 9.4.2-0lucid1 is pinned to priority 10, whereas packages normally from the partner repository have priority 500.

(b)
     9.4.2-0lucid1 0
         10 http://archive.canonical.com/ubuntu/ lucid/partner Packages

Means that all packages from the partner repository have priority 10, and the 0 means that the package has no special per-package priority.

We're all using pinning this way without much problems. But now, the problem you have is that you are pinning downwards, that is you try to decrease the priority of a version. That may not work correctly, but pinning upwards should always work. Thus, the solution for your problem is to always pin versions you want, not versions you don't want.

But that's not a case of specific pins not working. They do work. It just happens to be the case that the pinned version is always preferred over those without pins. I don't yet know why this is the case, but I'll take a closer look at it.

[Michal Suchanek (hramrach)]

It's so because pinning is buggy.

It's meant to pin both up and down, both * and specific packages, it is described so in the man page, and it does not work:

 APT also supports pinning by glob() expressions and regular expressions surrounded by /. For example, the following example
       assigns the priority 500 to all packages from experimental where the name starts with gnome (as a glob()-like expression)
       or contains the word kde (as a POSIX extended regular expression surrounded by slashes).

           Package: gnome* /kde/
           Pin: release n=experimental
           Pin-Priority: 500

Package: xserver-xorg*
Pin: release o=LP-PPA-xorg-edgers,a=natty,n=natty
Pin-priority: 300

xserver-xorg-core:
  Installed: 2:1.10.2.902-1ubuntu3
  Candidate: 2:1.10.3.902+git20110815+server-1.10-branch.4597f201-0ubuntu0sarvatt~natty
  Package pin: 2:1.10.3.902+git20110815+server-1.10-branch.4597f201-0ubuntu0sarvatt~natty
  Version table:
     2:1.10.3.902+git20110815+server-1.10-branch.4597f201-0ubuntu0sarvatt~natty 300
        990 http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/ natty/main amd64 Packages
 *** 2:1.10.2.902-1ubuntu3 300
        400 http://archive.ubuntu.mirror.dkm.cz/ oneiric/main amd64 Packages
        100 /var/lib/dpkg/status
     2:1.10.1-1ubuntu1.2 300
        990 http://archive.ubuntu.mirror.dkm.cz/ natty-updates/main amd64 Packages
     2:1.10.1-1ubuntu1 300
        990 http://archive.ubuntu.mirror.dkm.cz/ natty/main amd64 Packages
     2:1.9.2.901+git20101129+server-1.9-branch.65f2ab20-0ubuntu0sarvatt2~maverick 300
        292 http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/ maverick/main amd64 Packages
     2:1.9.0-0ubuntu7.3 300
        300 http://archive.ubuntu.mirror.dkm.cz/ maverick-updates/main amd64 Packages
     2:1.9.0-0ubuntu7 300
        300 http://archive.ubuntu.mirror.dkm.cz/ maverick/main amd64 Packages

[Vladimir Kuklin (vkuklin)]

Hi, I'm also experiencing this bug

e.g, pinning of mysql-client to specific repo depending on release information:

Package: mysql-client-5.5
Pin: release v=12.04,o=Ubuntu
Pin-Priority: 1002

Pins this priority to all packages including that ones that I do not want:

mysql-client-5.5:
  Installed: (none)
  Candidate: 5.5.31-0ubuntu0.12.04.1
  Package pin: 5.5.31-0ubuntu0.12.04.1
  Version table:
     5.5.31-0ubuntu0.12.04.1 1002
        500 http://srv11-msk.msk.mirantis.net/ubuntu-repo/mirror.yandex.ru/ubuntu/ precise-security/main amd64 Packages
        500 http://srv11-msk.msk.mirantis.net/ubuntu-repo/mirror.yandex.ru/ubuntu/ precise-updates/main amd64 Packages
     5.5.28-23.7ubuntu0.12.04.2+mirantis.wsrep3 1002
       1001 http://srv11-msk.msk.mirantis.net/ubuntu-repo/precise-fuel-folsom/ precise-2.1.0.1/main amd64 Packages
     5.5.22-0ubuntu1 1002
        500 http://srv11-msk.msk.mirantis.net/ubuntu-repo/mirror.yandex.ru/ubuntu/ precise/main amd64 Packages

[Julian Andres Klode (juliank)]

No, it does not. The pin value displayed after the version does not actually correspond to the version, but is the pin value of the candidate version. This is confusing, yes, we might want to change this in a future release.

[Rolf Leggewie (r0lf)]

Vladimir, I believe your output suggests things are actually working as expected. There's no effect of your pinning to 1002 (!) to be seen in what you posted.

[Julian Andres Klode (juliank)]

This bug is fixed in git's debian/experimental branch with a new policy algorithm that assigns pins to versions. It will most likely not hit Ubuntu 15.10, but I'm hopeful it will be included in 16.04.

[Darxus (darxus)]

Nice, that (debian) bug is 10 years old.

[Julian Andres Klode (juliank)]

Seems like we forgot to close this. This is fixed in 1.1