3

This has taken me two separate multi-hour sessions to fully comprehend exactly how the preferences.d system works in apt.

On my local dev machine, I have a lot of different apt sources .. :

/etc/apt/sources.list.d
; ls
total 64
-rw-r--r-- 1 root root  55 Jan 23 14:08 deb-backports.list
-rw-r--r-- 1 root root 158 Mar  4 06:05 deb-experimental.list
-rw-r--r-- 1 root root 164 Jan 23 14:23 deb-security.list
-rw-r--r-- 1 root root 146 Mar  4 06:05 deb-stable.list
-rw-r--r-- 1 root root 148 Mar  4 06:05 deb-testing.list
-rw-r--r-- 1 root root 150 Mar  4 06:05 deb-unstable.list
-rw-r--r-- 1 root root  42 Nov 30 22:35 dotdeb.list
-rw-r--r-- 1 root root  54 Nov 30 22:35 dotdeb.nginx-http2.list
-rw-r--r-- 1 root root 189 Oct  2 00:59 google-chrome.list
-rw-r--r-- 1 root root  49 Feb  6 18:51 suryorg-nginx.list <-- here
-rw-r--r-- 1 root root  47 Feb  6 18:53 suryorg-php.list   <-- here

To save a bit of typing, I have all of the same preferences in /etc/apt/preferences.d as this other ServerFault Question regarding apt pinning ... (even though this is mostly irrelevant) .. as well as one additional custom pinning rule for packages.sury.org, which provides two separate repositories for both nginx and php. (this is not irrelevant...)

This results in this apt-cache policy:

Package files:
 100 /var/lib/dpkg/status
     release a=now
 950 https://packages.sury.org/php/ jessie/main amd64 Packages
     release n=jessie,c=main
     origin packages.sury.org
 950 https://packages.sury.org/nginx/ jessie/main amd64 Packages
     release n=jessie,c=main
     origin packages.sury.org
 900 http://dl.google.com/linux/chrome/deb/ stable/main amd64 Packages
     release v=1.0,o=Google, Inc.,a=stable,n=stable,l=Google,c=main
     origin dl.google.com
 500 http://packages.dotdeb.org/ jessie-nginx-http2/all amd64 Packages
     release o=packages.dotdeb.org,a=jessie-nginx-http2,n=jessie-nginx-http2,l=packages.dotdeb.org,c=all
     origin packages.dotdeb.org
 500 http://packages.dotdeb.org/ jessie/all amd64 Packages
     release o=packages.dotdeb.org,a=jessie,n=jessie,l=packages.dotdeb.org,c=all
     origin packages.dotdeb.org
 500 http://ftp.us.debian.org/debian/ unstable/non-free Translation-en
 500 http://ftp.us.debian.org/debian/ unstable/main Translation-en
 500 http://ftp.us.debian.org/debian/ unstable/contrib Translation-en
  50 http://ftp.us.debian.org/debian/ unstable/non-free amd64 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=non-free
     origin ftp.us.debian.org
     ... { snipped }

I was very confused on how to pin custom/third party apt repositories, such as dotdeb and sury.org, until I figured out how to use the a=, n=, v=, c=, o=, as well as "origin" vs "release" options for the Pin: line, my sury.org, as described in apt_preferences man page. For example, doing a pin for dotdeb's multiple repositories is simple:

Package: *
Pin: release a=jessie
Pin-Priority: 500

Package: * 
Pin: release a=jessie-nginx-http2 
Pin-Priority: -1 

... with the "archive" line (a= bit) readily available via apt-cache policy. (Note: I don't understand if actually doing that particular example above would make sense in many situations, just a contrived example).

Then, we get to sury.org:

 950 https://packages.sury.org/php/ jessie/main amd64 Packages
     release n=jessie,c=main
     origin packages.sury.org
 950 https://packages.sury.org/nginx/ jessie/main amd64 Packages
     release n=jessie,c=main
     origin packages.sury.org

As you can see, the only thing specified here is the codename part (n=jessie) and no unique archive name, component, or label.

I tried to use the origin method, e.x.

Package: *
Pin: origin packages.sury.org
Pin-Priority: 950

And you can see above in the apt-cache policy output, this does work. However, there is no way to narrow it down to the individual /nginx/ or /php/ repository directory parts as far as I can tell. By putting the directory/path part in the "Pin:" line, it stops matching the rule. That is, ...

...
Pin: origin packages.sury.org/nginx/

Does not work as expected. Is there any workaround for this? Or is this simply a shortcoming of the sury.org maintainer (which no offense to them, they do a great job, .. this is just a bit of an edge case, and I am also just honestly curious)

Thank you very much for your time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.