severity 301075 normal thanks On Wed, Mar 23, 2005 at 10:53:03AM -0800, Chuan-kai Lin wrote: > On Wed, Mar 23, 2005 at 06:41:09PM +0100, Michael Schmitz wrote: > > > I think I ran into this a few months back. It had to do with > > > alternatives -- very odd. > > Odd indeed. I found a stale yacc alternatives file for bison (byacc) on > > kullervo, that might have prevented proper alternatives installation.
> This is not the first time this had happened -- see #289139. > > > It seems like I had to do something like > > > update-alternatives --auto yacc > > Which constitutes a bug in bison. > I respectfully disagree. The bison package handles alternatives the way > it is supposed to. There are two ways to look at the breakage: > 1. Another package (an old version of byacc, see #283174) broke the > alternatives system, and as a result bison installation fails to > work as expected. You can always break the alternatives system one > way or the other, and I do not consider it reasonable to blame the > resulting malfunction to bison. > 2. If you think that bison should work even under this specific > breakage (after all the byacc link is obviously stale), you need to > fix dpkg instead of bison. > > Funny enough, after a single invocation of update-alternatives --auto, > > it does. Hence, adding that to the postinst seems like a good idea. > > Bug filed. > This bug workaround overrides a system configuration option set by the > administrator, thus I do not consider it a valid fix. As I explained, > the right fix belongs in dpkg instead of bison anyway. > So this bug can go in one of the two directions: > 1. Nothing needs to be done. We close the bug. > 2. Something needs to be done. We assign this bug to dpkg. > Let me know your thoughts. In either event, it is not an RC bug in bison to clean up after byacc's historical breakage. Thanks, -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
