> Correct me if I am wrong: the problem is caused by a dangling link in > the alternatives system that refers to an uninstalled package. dpkg
Nope - even after removing that dangling link, bison does not properly install a new link. > knows that byacc is not installed, so in principle update-alternatives > should be able to remove the invalid alternative all by itself. > > Even if we fix the problem in bison properly (that means something other > than "update-alternatives --auto yacc"), the same issue will bite us > again when some other package forgets to remove alternatives on > uninstall. If we fix the problem in dpkg, we are not going to run into > the same issue again. That is why I think the fix (or rather, the > workaround) should be in dpkg instead in bison postinst. It's not about a dangling alternatives link - that you could detect, and rightly refuse to overwrite it ('the system administrator sure knows what he's doing'). I don't understand why, in the absence of any link, the alternative isn't installed without invoking --auto. On this, I'd like some input from the dpkg crew. > > dpkg can't be expected to know everything of that sort. If the byacc > > breakage is a known problem you should account for it. > > If byacc is not installed, then dpkg should be able to figure out that > the alternative is invalid. Furthermore there is no good way to fix the As I said above - it doesn't matter if the old link is still present or not. > issue in bison: "update-alternatives --auto yacc" overrides system admin > configuration and will annoy a whole bunch of other people. If there's no alternative set, why not install the logical one? I.e. if there's no link found, just use --auto? I must be missing something. Where else does update-alternatives look for clues? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]