On Wed, 2022-01-12 at 14:17:17 +0100, Vincent Lefevre wrote: > On 2022-01-12 13:13:23 +0100, Guillem Jover wrote: > > From this log, it looks like on 2021-12-06 you upgraded, and probably > > got dpkg 1.20.0, which then lost the alternatives, and restored the > > ones for gnome-terminal and rxvt, the other ones are then missing, > > even after restoring the misplaced db. :/ Unfortunately w/o > > declarative alternatives the current restoring logic is the best that > > can be done, that will not leave cruft behind. > > I'm not sure I understand what you mean. dpkg 1.20.0 is very old. > Perhaps you meant dpkg 1.21.0.
Err, yeah sorry. > Indeed, on this machine, dpkg 1.21.0 > was installed on 2021-12-06 13:39:35. Then, do you mean that this > was actually a bug in dpkg 1.21.0, which got fixed in 1.21.1, but > alternatives settings had already been lost? Yes and no. dpkg 1.21.0 had a bug where u-a would read and write its db directly into /var/lib/dpkg (instead of within its alternatives/ subdir). Which meant that when removing or installing alternatives it would ignore all existing ones. The recovery code I added in 1.21.1 moved any alternatives state file from /var/lib/dpkg/ back into /var/lib/dpkg/alternatives, but at that point (further) state loss would happen. My thinking was that this version was on the archive for 1 day, that alternatives are currently mostly self-healing (just reinstalling or upgrading would recover the db, although it might lose the manual/auto state). And that leaving lingering alternatives behind (after a removal of an alternative with the bogus detached db not affecting the real db) was worse than the other scenarios, as that was not self-healing. So went for overwriting any alternatives state file that had been newly created directly under /var/lib/dpkg/. Just to be clear, the other options would have been: - simply remove the detached alternatives state files from /var/lib/dpkg/, missing alternative removals which are not self-healing, unless the package gets installed and removed again. - try to merge both, but I don't see how removals could be handled here, so it might cover component updates in alternatives better but it still would have the same problem as the previous one at a way higher implementation cost. > If this is the case, > is there a way to know which alternatives are missing? Those that > appear in /var/log/alternatives.log* while dpkg 1.20.0 was installed? As long as alternatives.log has been kept for long enough, otherwise grepping for u-a in maintscripts in the dpkg db might be more effective. > I can see that on another machine, dpkg was upgraded directly from > 1.20.9 to 1.21.1, and I haven't noticed any issue there. Right. And sorry for the trouble! Thanks, Guillem
