On 8/19/26 13:30, Guillem Jover wrote:
Control: tag -1 moreinfo unreproducible
On one of my machines where this issue has been found, the file
/var/lib/dpkg/available seems to has been created during initial
install, and never updated. It contains information about packages
which were available back in 2015. And `dpkg --set-selections'
updates some info about installed packages from this file. For
example, it "fixed" Priority for e2fsprogs from optional to
required, changed libcap2 priority from optional to standard,
changed tzdata section from localization to libs and so on -
more than 50 changes in total. Obviously this is all wrong now
for current packages, but it was correct back 11 years ago.
Right, unless something updates the available file explicitly,
either via one of «dpkg --record-avail», «dpkg --update-avail» or
«dpkg --merge-avail», the file is no longer automatically updated
during unpack (since 2014), because those installed files were not
guaranteed to be available for re-installation anyway, as dpkg was
not recording the pathnames to locate them.
Something else that is happening is that during unpack/install dpkg
takes the Section and Priority values from the actual .deb archives,
instead of the repo Packages files, where any archive overrides will
then get ignored, and discrepancies could happen this way.
Otherwise I'm not sure I understand the reported problem, and I cannot
reproduce it locally on a chroot, also with a stale available file.
The command I was using to discover this was
apt purge kitty-terminfo
(an arbitrary package). After that, Priorities/etc gets synced from
the old `available` file. This apt command makes several calls to dpkg,
and the problematic one is:
echo 'kitty-terminfo:all purge' | /usr/bin/dpkg --set-selections
This is where dpkg updates other fields from the outdated `available`.
So it is the --set-selections subcommand which does that -- it does
not only acts on the info it is given on the command line or stdin,
but also looks at that `available` file and merges info from there.
Hopefully this makes things clear. I'm sorry I haven't included these
details in the initial report - it was a long yak shaving session :)
Thanks,
/mjt
