Control: tag -1 moreinfo unreproducible On Wed, 2026-08-12 at 11:36:54 +0300, Michael Tokarev wrote: > Package: dpkg > Version: 1.22.22 > Severity: normal
> When doing `apt purge', apt runs `dpkg --set-selections' as one of the > steps. And during this step, dpkg updates some fields of installed > packages from its `available' database. In theory dpkg only updates fields to be written into the status file from the "available" information (extracted from the .deb archive being installed, and not from the available file, since 2014), during unpack or install. AFAIR during remove/purge dpkg should not be updating any section or priority fields. > 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. > Apparently we shoud decide whenever we should keep this file > up to date, or drop it. But doing it this way is wrong. This is certainly a valid question, which has been pending on a decision depending on how better front-end integration should pan out, see [R] at the end. But I'm not sure it affects the reported problem here. [R] https://wiki.debian.org/Teams/Dpkg/RoadMap Thanks, Guillem
