Control: tag -1 - moreinfo unreproducible Hi!
On Wed, 2026-08-19 at 15:32:26 +0300, Michael Tokarev wrote: > On 8/19/26 13:30, Guillem Jover wrote: > > Control: tag -1 moreinfo unreproducible > > 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 :) 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
