On Lu, 30 mar 20, 12:47:45, Martin wrote: > On Sun, 29 Mar 2020 at 20:59, Andrei POPESCU <andreimpope...@gmail.com> wrote: > > > > > For my apt preferences I had: > > > > > > Package: * > > > Pin: release a=testing > > > Pin-Priority: 650 > > > > > > Package: * > > > Pin: release a=unstable > > > Pin-Priority: 600 > > > > > > To be honest back in the day when I did that, I struggled to really > > > understand it. My intention was to have the system take packages from > > > unstable and if a package is not available there then from testing. > > > Does it even do that? > > > > It does the exact opposite, because in your configuration testing has > > higher priority. > > > > For what you wrote above you don't need any pinning, just have both > > unstable and testing your sources.list. > > Great, thank you very much for clearing this up for me! Problems solved!
To explain, apt by default will always prefer the newest version it can find in your repositories. Pins are only necessary if for some reason you want to override that. If you intend to stay on unstable it is safe to remove the pins completely and still retain testing in sources.list (having testing in sources.list when running unstable is a good idea anyway). As for bugs in individual packages, you need a negative pin (any value below 0) for the specific version with the bug. That way a newer version (hopefully without the bug) will be installed automatically. If you are using aptitude there is also 'forbid-version' which does the same. A pin with a value > 1000 (any value) will force apt to keep the package at that version, regardless of what updates are available. As you found out, this will block regular updates that explicitly require a newer version of the pinned package. One has to decide on a case-by-case basis what is more important (pin or updates). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Description: PGP signature
