[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#301075: On #301075: bison and yacc alternatives



> 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



Reply to: