unattended-upgrades not considering pin-priority

[ryaeng]

Hello everyone,

I've run into the issue a few times where unattended-upgrades doesn't take pin-priority into account. When looking through the codebase, I found the following:

• unattended-upgrades/data/50unattended-upgrades.Ubuntu

  Line 131 in 94bd1f1

  // Unattended-Upgrade::Allow-downgrade "false";

That line indicates that it's possible for unattended-upgrades to consider pin-priority but it doesn't by default. Is this the desired effect or a bug?

We utilize pin-priority to tightly couple many nvidia packages together. This is necessary when dealing with a number of packages for AI/ML. When unattended-upgrades is run, it tends to break systems and drivers. Please advise.

[ryaeng]

Update regarding the aforementioned config. Added that to 52unattended-upgrade and set it to true. This did not work. When unattended-upgrade ran after making this change, it upgraded packages without taking pin-priority into account.

My recommendation going forward is to blacklist packages.

[julian-klode]

Pinning works within the confines of the requirements:

Pinning for sources that are not allowed are pinned to "never", overriding any pin configured for then.

If you want to pin a lower version, you also need to add that to the list of allowed origins, achieve the pin by pinning down the versions you don't want, or as you did block the package.

I've explained this in an older issue here that is open, feel free to find and read it for more details.

[ryaeng]

@julian-klode Thanks for the reply. Why is it setup this way? Since users typically use apt upgrade, my thought is that unattended-upgrade would run as close to this as possible.

That did work though. I added our repo to AllowedOrigins via 52unattended-upgrade-local. Running --debug proves that it holds back the proper packages. Thank you.