Acknowledgement sent
to Martin Schmitt <[email protected]>:
New Bug report received and forwarded. Copy sent to APT Development Team <[email protected]>.
(Thu, 27 Oct 2022 10:27:04 GMT) (full text, mbox, link).
Package: apt
Version: 2.5.3+b1
Severity: minor
We're maintaining an alternative unattended-upgrades cycle for a single
internal APT source and while implementing it, we discovered the
following
in /usr/lib/apt/apt.systemd.daily:
Near the beginning of main(), the script finds the value of the APT
configuration option "Dir::State" to create its lock file:
eval $(apt-config shell StateDir Dir::State/d)
However, the default value for Dir::State, /var/lib/apt, is hardcoded
throughout the entire script:
$ grep var.lib.apt /usr/lib/apt/apt.systemd.daily
BACKUP_ARCHIVE_STAMP=/var/lib/apt/periodic/backup-archive-stamp
if test -r /var/lib/apt/extended_states; then
if ! cmp -s apt.extended_states.0 /var/lib/apt/extended_states; then
cp -p /var/lib/apt/extended_states apt.extended_states
UPDATE_STAMP=/var/lib/apt/periodic/update-stamp
DOWNLOAD_UPGRADEABLE_STAMP=/var/lib/apt/periodic/download-upgradeable-stamp
UPGRADE_STAMP=/var/lib/apt/periodic/upgrade-stamp
CLEAN_STAMP=/var/lib/apt/periodic/clean-stamp
AUTOCLEAN_STAMP=/var/lib/apt/periodic/autoclean-stamp
This is especially irritating because /usr/bin/unattended-upgrade, which
is
executed from /usr/lib/apt/apt.systemd.daily does obey the configuration
from Dir::State and even creates its own "periodic" sub directory there.
We ultimately found that changing Dir::State was not required for what
we
did, nevertheless I'm reporting this as a minor bug.