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";

I replaced it with the file 51unattended-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 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:


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

  • I have a major problem with the equal siign in the first line LMDE 5 is absolutely not equal to Bullseye! It might be based on Debian, but it absolutely is not Debian. Sep 17, 2023 at 22:40
  • It was a bit of a "mental shortcut" because the UU issue is identical in LMDE5 and Bullseye. But you're right - the equals sign is not the best designation. I corrected it.
    – DarekH
    Sep 18, 2023 at 13:10

1 Answer 1


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).

  • Please look at my edit. Can this be fixed or am I only left with option 1 and option 2?
    – DarekH
    Sep 17, 2023 at 14:30
  • I deleted my edit because I made a syntax error - I typed site: instead of site=. Now it works beautifully! StackExchange advises against saying thanks, but my heart tells me otherwise and I can't help myself :) Thanks a lot!
    – DarekH
    Sep 17, 2023 at 14:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .