Dear Maintainer,

I found that configuration fragments in /etc/apt/listchanges.conf.d/ are loaded in a nondeterministic order.

This caused different effective configurations on two Debian 13 systems even though they had the same apt-listchanges version and identical configuration files.

The relevant code in apt_listchanges/ALCConfig.py is:

    configs = [conf]
    configs += glob(os.path.join(conf_d, '*.conf'))
    self.read(configs)

Python's glob() does not guarantee any particular ordering. Therefore the order in which configuration fragments override each other depends on the directory enumeration order.

I reproduced this on two OpenMediaVault systems running Debian 13 and apt-listchanges 4.8.

Both systems contained these files:

    /etc/apt/listchanges.conf.d/95openmediavault.conf
    /etc/apt/listchanges.conf.d/98openmediavault-mail.conf

95openmediavault.conf contains:

    [apt]
    which=both
    email_address=none
    email_format=html
    headers=false
    reverse=false
    titled=true

98openmediavault-mail.conf contains:

    [apt]
    email_address=root

On the affected system, glob() returned:

    /etc/apt/listchanges.conf.d/98openmediavault-mail.conf
    /etc/apt/listchanges.conf.d/95openmediavault.conf

The resulting effective configuration was:

    frontend        = 'pager'
    which           = 'both'
    email_address   = None
    email_format    = 'html'

As a result, apt-listchanges did not send email because can_send_emails() returned False.

On another system with the same apt-listchanges version and the same configuration files, glob() returned:

    /etc/apt/listchanges.conf.d/95openmediavault.conf
    /etc/apt/listchanges.conf.d/98openmediavault-mail.conf

The resulting effective configuration was:

    email_address   = 'root'

and apt-listchanges email notifications worked correctly.

I tested the following one-line change on the affected system:
--- a/apt_listchanges/ALCConfig.py
+++ b/apt_listchanges/ALCConfig.py
@@
-        configs += glob(os.path.join(conf_d, '*.conf'))
+        configs += sorted(glob(os.path.join(conf_d, '*.conf')))

After applying this change, the effective configuration became:

    email_address = 'root'
    which         = 'both'
    email_format  = 'html'

I then performed a normal APT upgrade. The apt-listchanges hook ran normally and the expected apt-listchanges email was successfully sent.

Therefore, sorting the configuration fragment filenames before passing them to ConfigParser appears to fix the issue and makes the override order deterministic.

The problem was reproduced with apt-listchanges 4.8 from Debian trixie. I have not tested whether 4.8+nmu3 in testing/unstable is affected.

Regards,
Kenichiro Kakizaki

Good catch, and good fix. I will apply it. Do you want credit in the
changelog, and if so, how would you like to be credited?