Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1089357

Bug#1003452: dpkg: missing alternatives for x-terminal-emulator

Cross-posted to 2 groups.

Show all headers | View raw

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

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Bug#1003452: dpkg: missing alternatives for x-terminal-emulator Vincent Lefevre <vincent@vinc17.net> - 2022-01-10 13:20 +0100
  Bug#1003452: dpkg: missing alternatives for x-terminal-emulator Guillem Jover <guillem@debian.org> - 2022-01-12 13:20 +0100
    Bug#1003452: dpkg: missing alternatives for x-terminal-emulator Vincent Lefevre <vincent@vinc17.net> - 2022-01-12 14:30 +0100
      Bug#1003452: dpkg: missing alternatives for x-terminal-emulator Guillem Jover <guillem@debian.org> - 2022-01-13 13:30 +0100
        Bug#1003452: dpkg: missing alternatives for x-terminal-emulator Vincent Lefevre <vincent@vinc17.net> - 2022-01-13 14:10 +0100

csiph-web