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.

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.

Apparently we shoud decide whenever we should keep this file
up to date, or drop it.  But doing it this way is wrong.

Thanks,

/mjt

Control: tag -1 moreinfo unreproducible

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.

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.

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

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

Hi!

Ah! Yes, thanks for remarking again on the --set-selections part. It
does make sense now. :)

The problem is that internally the priority and section is shared for
both the status and available instances. And although there is some
logic to avoid updating them in some conditions, that does not apply
when we load the available file, so in the --set-selections case, the
older information from the available file will overwrite the shared
data for the status file.

This is something that has always bothered me, because it means that
«dpkg -s» and «dpkg -p» cannot provide (more) reliable information!
And where we have this heuristic for when to update the info (to honor
the archive overrides), instead of just taking it always from the
package.

So, I think I change these fields to stop being shared, so that we do
not lose information. And eventually maybe add a way to override
specific values by a frontend (so that this kind of divergence can be
resolved. OTOH having the divergence being visible, means it can be
fixed at the source. :)

(I'm preparing the changes, but I'm not sure I'll include them for
1.23.8 because I see potential for regressions, and that version has
already been delayed for too long. But definitely for the next
non-regression release.)

Thanks,
Guillem