Unattended-Upgrades configuration for custom repo only

OS: LMDE 5 (based on Debian 11 Bullseye)

To keep the system tidy, I use separate files to overrides the original distribution/developer configuration files wherever possible. This also prevents problems when the developer makes changes to the original config and keeps my settings safe. etc…

For Unattended-Upgrades, the original configuration of /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Origins-Pattern {
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

I replaced it with the file 51unattended-upgrades:

Unattended-Upgrade::Origins-Pattern {
        "site=myrepo.example.com"
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
//      "origin=Debian,codename=${distro_codename},label=Debian";
//      "origin=Debian,codename=${distro_codename},label=Debian-Security";
//      "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

I thought the entire original section would be replaced with my section and UU would only update myrepo.example.com. But it turns out that all 4 repositories are active:

"site=myrepo.example.com"
"origin=Debian,codename=${distro_codename},label=Debian"
"origin=Debian,codename=${distro_codename},label=Debian-Security"
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security"

How can I disable all other repos and only have myrepo active without changing the original 50unattended-upgrades?

Asked By: DarekH

||
Source

The configuration file /etc/apt/apt.conf.d/50unattended-upgrades isn’t directly part of the package unattended-upgrades. Upgrades of this file are managed by its install scripts through helper tools (mostly dpkg-maintscript-helper and ucf --three-way --debconf-ok as seen for example in the postinst file): among other things it checks if the file was altered before replacing it with a new maintainer version (and will usually prompt about this with the default of keeping the altered version). The original reference is safely stored at /usr/share/unattended-upgrades/50unattended-upgrades.

Having told all this, options can be:

  1. change directly 50unattended-upgrades: Debian will respect the change and prompt for what to do (with an initial default of "keep changed version") if needed.

  2. copy it into an other file (51unattended-upgrades) and empty this file (but keep it). As above, Debian will respect the change etc.

Or there’s a specific APT-related way for APT configurations:

  1. Use specific apt.conf(5) syntax to forget a former tree, and then replace it with newer values.

    This is documented in apt.conf(5) (emphases mine):

    […] #clear is used to erase a part of the configuration tree. The specified element and all its descendants are erased. (Note that these
    lines also need to end with a semicolon.)

    The #clear command is the only way to delete a list or a complete
    scope.     Reopening a scope (or using the syntax described below with an
    appended ::) will not override previously written entries.     Options can
    only be overridden by addressing a new value to them – lists and
    scopes can    ‘t be overridden, only cleared.

    Documentation is a bit scarce. By trial-and-error tests (more easily done on the needrestart package’s configuration) it’s: #clear Some::Tree; and also "Directives can only be done at the top level", ie: it must be called on a fully qualified scope outside of any scope, rather than within a scope to be applied on a sub-scope.

So the 51unattended-upgrades file could start with:

#clear Unattended-Upgrade::Origins-Pattern;

to reset the list to an empty list before repopulating it with what follows in this file. Then it’s possible to not have to change 50unattended-upgrades at all and still use its other default settings if any.

Whatever method 1. 2. or 3. in use, the administrator will still have to check what changes appear between two Debian release version (major) upgrades. Eg: security repository URL schema had a change between Debian 10 and Debian 11: this would have had to be adapted manually when (re)defining Unattended-Upgrade::Origins-Pattern after an upgrade from Debian 10 to Debian 11 (doesn’t apply for OP’s specific case which intends to disallow security upgrades too).

Answered By: A.B