Package: dpkg Version: 1.19.2 Severity: serious Control: found -1 1.18.25 Hi,
there is a problem with update-alternatives not properly deregistering obsolete slaves: ========== #!/bin/sh update-alternatives --version update-alternatives --remove-all foobar set -x touch /foo /foo.1 touch /bar /bar.1 update-alternatives --display foobar update-alternatives --install /foobar foobar /foo 23 --slave /foobar.1 foobar-1 /foo.1 --slave /barfoo barfoo /bar --slave /barfoo.1 barfoo-1 /bar.1 update-alternatives --display foobar rm /bar /bar.1 update-alternatives --install /foobar foobar /foo 42 --slave /foobar.1 foobar-1 /foo.1 update-alternatives --display foobar update-alternatives --install /foobar foobar /foo 42 --slave /foobar.1 foobar-1 /foo.1 update-alternatives --display foobar ========== # ./foobar.sh Debian update-alternatives version 1.18.25. This is free software; see the GNU General Public License version 2 or later for copying conditions. There is NO warranty. update-alternatives: error: no alternatives for foobar + touch /foo /foo.1 + touch /bar /bar.1 + update-alternatives --display foobar update-alternatives: error: no alternatives for foobar + update-alternatives --install /foobar foobar /foo 23 --slave /foobar.1 foobar-1 /foo.1 --slave /barfoo barfoo /bar --slave /barfoo.1 barfoo-1 /bar.1 update-alternatives: using /foo to provide /foobar (foobar) in auto mode + update-alternatives --display foobar foobar - auto mode link best version is /foo link currently points to /foo link foobar is /foobar slave barfoo is /barfoo slave barfoo-1 is /barfoo.1 slave foobar-1 is /foobar.1 /foo - priority 23 slave barfoo: /bar slave barfoo-1: /bar.1 slave foobar-1: /foo.1 + rm /bar /bar.1 + update-alternatives --install /foobar foobar /foo 42 --slave /foobar.1 foobar-1 /foo.1 update-alternatives: warning: forcing reinstallation of alternative /foo because link group foobar is broken + update-alternatives --display foobar foobar - auto mode link best version is /foo link currently points to /foo link foobar is /foobar slave barfoo-1 is /barfoo.1 slave foobar-1 is /foobar.1 *** *** *** at this point there should not be any barfoo slaves left *** *** *** /foo - priority 42 slave foobar-1: /foo.1 + update-alternatives --install /foobar foobar /foo 42 --slave /foobar.1 foobar-1 /foo.1 + update-alternatives --display foobar foobar - auto mode link best version is /foo link currently points to /foo link foobar is /foobar slave foobar-1 is /foobar.1 /foo - priority 42 slave foobar-1: /foo.1 # sh foobar.sh Debian update-alternatives version 1.17.27. This is free software; see the GNU General Public License version 2 or later for copying conditions. There is NO warranty. update-alternatives: error: no alternatives for foobar + touch /foo /foo.1 + touch /bar /bar.1 + update-alternatives --display foobar update-alternatives: error: no alternatives for foobar + update-alternatives --install /foobar foobar /foo 23 --slave /foobar.1 foobar-1 /foo.1 --slave /barfoo barfoo /bar --slave /barfoo.1 barfoo-1 /bar.1 update-alternatives: using /foo to provide /foobar (foobar) in auto mode + update-alternatives --display foobar foobar - auto mode link currently points to /foo /foo - priority 23 slave barfoo: /bar slave barfoo-1: /bar.1 slave foobar-1: /foo.1 Current 'best' version is '/foo'. + rm /bar /bar.1 + update-alternatives --install /foobar foobar /foo 42 --slave /foobar.1 foobar-1 /foo.1 update-alternatives: warning: forcing reinstallation of alternative /foo because link group foobar is broken + update-alternatives --display foobar foobar - auto mode link currently points to /foo /foo - priority 42 slave foobar-1: /foo.1 Current 'best' version is '/foo'. + update-alternatives --install /foobar foobar /foo 42 --slave /foobar.1 foobar-1 /foo.1 + update-alternatives --display foobar foobar - auto mode link currently points to /foo /foo - priority 42 slave foobar-1: /foo.1 Current 'best' version is '/foo'. So this is reproducible in stretch, too, but not in jessie. The change of priority is not even needed. The problem does not occur if there is only a single broken slave to be removed. The slaves to be removed don't even need to be broken ... # update-alternatives --install /test test /bin 1 --slave /one one /bin --slave /two two /bin --slave /three three /bin # update-alternatives --install /test test /bin 1 # update-alternatives --install /test2 test2 /bin 1 --slave /one one /bin --slave /two two /bin --slave /three three /bin update-alternatives: error: alternative three can't be slave of test2: it is a slave of test # update-alternatives --display test test - auto mode link best version is /bin link currently points to /bin link test is /test slave three is /three /bin - priority 1 This didn't work with only two slaves being removed ... Also the "forcing reinstallation of alternative ..." message is confusing at this situation, as there is nothing left to be "fixed" after the new alternative got "applied", since the new alternative is supposed to fix the currently broken bits. That message might be useful if the alternative is set to manual or a lower priority is being installed, that would not imply any changes to the currently selected alternative (which has broken slave links). Or if the currently selected alternative was about to be reinstalled with the same parameters s.t. it should be a no-op. The message when adding new slaves looks much more appropriate: "updating alternative ... because link group ... has changed slave links" ---------- And here is the text that I initially wrote for this bug, with a real life example, before trying to reproduce it with a few commands: The current alternative has a broken link group, because some slave targets are gone. The new alternative has these slaves removed and changes the priority value. u-a does not properly install the new alternative, because it keeps the broken link in the registry. Instead it gives the "forcing reinstallation" message, which is a bit confusing. Reinstalling the alternative with the same command works fine and cleans up the cruft entry. Works the same with and without priority change. I noticed this problem in a piuparts upgrade test of the nvidia driver packages in non-free. The slave alternative is supposed to be taken over by another package (and another alternative), but suddenly u-a started to complain that it is still owned by the old alternative. + update-alternatives --display nvidia nvidia - auto mode link best version is /usr/lib/nvidia/current link currently points to /usr/lib/nvidia/current link nvidia is /usr/lib/nvidia/nvidia slave nvidia--libGL.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 slave nvidia--libGLX_indirect.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 /usr/lib/nvidia/current - priority 384 slave nvidia--libGL.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1 slave nvidia--libGLX_indirect.so.0-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_indirect.so.0 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 + update-alternatives --install /usr/lib/nvidia/nvidia nvidia /usr/lib/nvidia/current 390 --slave /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 update-alternatives: warning: forcing reinstallation of alternative /usr/lib/nvidia/current because link group nvidia is broken + update-alternatives --display nvidia nvidia - auto mode link best version is /usr/lib/nvidia/current link currently points to /usr/lib/nvidia/current link nvidia is /usr/lib/nvidia/nvidia slave nvidia--libGLX_indirect.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 /usr/lib/nvidia/current - priority 390 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 # ls -la /etc/alternatives/nvidia* lrwxrwxrwx 1 root root 23 Dec 18 17:12 /etc/alternatives/nvidia -> /usr/lib/nvidia/current lrwxrwxrwx 1 root root 59 Dec 18 17:12 /etc/alternatives/nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 # ls -la /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 ls: cannot access '/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0': No such file or directory # update-alternatives --install /usr/lib/nvidia/nvidia nvidia /usr/lib/nvidia/current 391 --slave /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 # update-alternatives --display nvidia nvidia - auto mode link best version is /usr/lib/nvidia/current link currently points to /usr/lib/nvidia/current link nvidia is /usr/lib/nvidia/nvidia slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 /usr/lib/nvidia/current - priority 391 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 I thought this was a recent regression, since this worked a few months ago when I tested this upgrade path in the nvidia driver package. But obviously it is not, perhaps there are some more circumstances needed to have this manifest. Andreas