yacc/bison breakage on kullervo chroot, please reschedule etpan-ng

[Debian Bug Importer]

Automatically imported from Debian bug report #301075 http://bugs.debian.org/301075

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #301075 http://bugs.debian.org/301075

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 23 Mar 2005 18:41:09 +0100 (CET)
From: Michael Schmitz <email address hidden>
To: Stephen R Marenka <email address hidden>
cc: Gerfried Fuchs <email address hidden>, <email address hidden>,
        <email address hidden>
Subject: Re: yacc/bison breakage on kullervo chroot, please reschedule etpan-ng

Package: bison
Version: 1.875d-1
Severity: serious

Synopsis: installation of bison does not properly install the yacc
alternatives symlinks - see below.

> 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.

> /usr/bin/yacc needs to point to /etc/alternatives/yacc
> /etc/alternatives/yacc needs to point to /usr/bin/bison.yacc

Which should be taken care of by bison's postinstall script.

> It seems like I had to do something like
> update-alternatives --auto yacc

Which constitutes a bug in bison.

This section of bison.postinst

if [ $1 != "upgrade" ] ; then
 update-alternatives --install /usr/bin/yacc yacc /usr/bin/bison.yacc 100 \
  --slave /usr/share/man/man1/yacc.1.gz yaccman /usr/share/man/man1/bison.1.gz

fi

doesn't work at all.

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.

 Michael

[Chuan-kai Lin (cklin-cs)]

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.

--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/

[Debian Bug Importer (debzilla)]

Message-ID: <20050323185303.GA19218@rho>
Date: Wed, 23 Mar 2005 10:53:03 -0800
From: Chuan-kai Lin <email address hidden>
To: Michael Schmitz <email address hidden>, Bug 301075 <email address hidden>
Cc: Stephen R Marenka <email address hidden>, Gerfried Fuchs <email address hidden>,
 m68k Build <email address hidden>
Subject: On #301075: bison and yacc alternatives

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.

--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/

[Steve Langasek (vorlon)]

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

[Matt Zimmerman (mdz)]

This bug has been marked as a duplicate of bug 9923.

[Matt Zimmerman (mdz)]

Wrong bug

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 23 Mar 2005 14:01:30 -0800
From: Steve Langasek <email address hidden>
To: Chuan-kai Lin <email address hidden>, <email address hidden>
Cc: Michael Schmitz <email address hidden>,
 Stephen R Marenka <email address hidden>,
 Gerfried Fuchs <email address hidden>, m68k Build <email address hidden>
Subject: Re: Bug#301075: On #301075: bison and yacc alternatives

--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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,
--=20
Steve Langasek
postmodern programmer

--Qxx1br4bt0+wmkIi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCQec2KN6ufymYLloRAjQdAKDSc1rmnoAUgekpJZQpRuhb9T59dwCeNqkt
3/o2UtGqDwnpThstogbYlec=
=HB/U
-----END PGP SIGNATURE-----

--Qxx1br4bt0+wmkIi--

[LaMont Jones (lamont)]

This is a dup of debian bug 283174, which was closed in byacc_1.9.1-1.1 in
debian, by yours truly, and then sync'd to hoary in Nov 2004. But since we lack
that bug in bz, closing as NOTABUG.

[Michael Schmitz (schmitz-opal)]

> > 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.

I strongly doubt it's dpkg's fault. After all, handling compatibility
problems of that sort is supposed to happen in postinst (which is what I
suggested).

> > 1. Nothing needs to be done. We close the bug.
>
> > 2. Something needs to be done. We assign this bug to dpkg.

dpkg can't be expected to know everything of that sort. If the byacc
breakage is a known problem you should account for it.

> > Let me know your thoughts.
>
> In either event, it is not an RC bug in bison to clean up after byacc's
> historical breakage.

Conceded - I still consider it a bug nonetheless.

Thanks for demonstrating the power of RC bugs in making life easier for us
autobuild maintainers.

 Michael

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 24 Mar 2005 09:14:11 +0100 (CET)
From: Michael Schmitz <email address hidden>
To: Steve Langasek <email address hidden>
cc: Chuan-kai Lin <email address hidden>, <email address hidden>,
 Michael Schmitz <email address hidden>,
 Stephen R Marenka <email address hidden>,
 Gerfried Fuchs <email address hidden>, m68k Build <email address hidden>
Subject: Re: Bug#301075: On #301075: bison and yacc alternatives

> > 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.

I strongly doubt it's dpkg's fault. After all, handling compatibility
problems of that sort is supposed to happen in postinst (which is what I
suggested).

> > 1. Nothing needs to be done. We close the bug.
>
> > 2. Something needs to be done. We assign this bug to dpkg.

dpkg can't be expected to know everything of that sort. If the byacc
breakage is a known problem you should account for it.

> > Let me know your thoughts.
>
> In either event, it is not an RC bug in bison to clean up after byacc's
> historical breakage.

Conceded - I still consider it a bug nonetheless.

Thanks for demonstrating the power of RC bugs in making life easier for us
autobuild maintainers.

 Michael

[Chuan-kai Lin (cklin-cs)]

On Thu, Mar 24, 2005 at 09:14:11AM +0100, Michael Schmitz wrote:
> > > 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.

> I strongly doubt it's dpkg's fault. After all, handling compatibility
> problems of that sort is supposed to happen in postinst (which is what
> I suggested).

[I cc'ed the dpkg developers in hope of getting some opinions.]

If you think some package should take care of this problem, we need to
figure out what is the best place to fix this problem. I agree it is
not dpkg's fault, and I am only saying that the workaround should be in
dpkg instead of in bison postinst.

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
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.

> > > 1. Nothing needs to be done. We close the bug.
> > > 2. Something needs to be done. We assign this bug to dpkg.

> 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
issue in bison: "update-alternatives --auto yacc" overrides system admin
configuration and will annoy a whole bunch of other people.

How do you expect bison to "account for" the byacc breakage?

> Thanks for demonstrating the power of RC bugs in making life easier
> for us autobuild maintainers.

Wow, take it easy, man. There is no need to be sarcastic. We do want
to help make your life easy. But that does not mean we should go making
the wrong changes where they do not belong.

There are simpler ways to make your life easier. The fixed byacc is in
testing, and if you clean up any invalid byacc alternatives in the
chroot environments, they are not going to show up again. Much faster
than waiting for fixed bison/dpkg/whatever to enter testing.

--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/

[Debian Bug Importer (debzilla)]

Message-ID: <20050324214619.GA8629@rho>
Date: Thu, 24 Mar 2005 13:46:19 -0800
From: Chuan-kai Lin <email address hidden>
To: Michael Schmitz <email address hidden>
Cc: Steve Langasek <email address hidden>, Bug 301075 <email address hidden>,
 Stephen R Marenka <email address hidden>,
 Gerfried Fuchs <email address hidden>, m68k Build <email address hidden>,
 dpkg <email address hidden>
Subject: Re: Bug#301075: On #301075: bison and yacc alternatives

On Thu, Mar 24, 2005 at 09:14:11AM +0100, Michael Schmitz wrote:
> > > 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.

> I strongly doubt it's dpkg's fault. After all, handling compatibility
> problems of that sort is supposed to happen in postinst (which is what
> I suggested).

[I cc'ed the dpkg developers in hope of getting some opinions.]

If you think some package should take care of this problem, we need to
figure out what is the best place to fix this problem. I agree it is
not dpkg's fault, and I am only saying that the workaround should be in
dpkg instead of in bison postinst.

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
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.

> > > 1. Nothing needs to be done. We close the bug.
> > > 2. Something needs to be done. We assign this bug to dpkg.

> 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
issue in bison: "update-alternatives --auto yacc" overrides system admin
configuration and will annoy a whole bunch of other people.

How do you expect bison to "account for" the byacc breakage?

> Thanks for demonstrating the power of RC bugs in making life easier
> for us autobuild maintainers.

Wow, take it easy, man. There is no need to be sarcastic. We do want
to help make your life easy. But that does not mean we should go making
the wrong changes where they do not belong.

There are simpler ways to make your life easier. The fixed byacc is in
testing, and if you clean up any invalid byacc alternatives in the
chroot environments, they are not going to show up again. Much faster
than waiting for fixed bison/dpkg/whatever to enter testing.

--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/

[Michael Schmitz (schmitz-zirkon)]

> 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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 26 Mar 2005 11:25:42 +0100 (CET)
From: Michael Schmitz <email address hidden>
To: Chuan-kai Lin <email address hidden>
cc: Michael Schmitz <email address hidden>, Bug 301075 <email address hidden>,
 Stephen R Marenka <email address hidden>,
 Gerfried Fuchs <email address hidden>, m68k Build <email address hidden>,
 dpkg <email address hidden>
Subject: 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

[Chuan-kai Lin (cklin-cs)]

On Sat, Mar 26, 2005 at 11:25:42AM +0100, Michael Schmitz wrote:
> 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.

(Note: I trimmed m68k-build from the CC list)

Well, maybe "dangling alternative" is a better term than "dangling link"
(I use "dangling" to describe a reference whose destination does not
exist). I think dpkg maintains the alternatives database in
/var/lib/dpkg/alternatives, so merely removing the old byacc symlink in
/etc/alternatives or whatever does not do the trick. We need to do
"update-alternatives --remove" to completely remove the dangling
alternative.

What I was suggesting was that dpkg knows the following things:

 1. bison is trying to set up an alternative for yacc
 2. The yacc alternative is pointed to byacc
 3. The byacc program does not exist, and does not belong to any
    currently installed package

So in principle dpkg should be able to determine that the byacc
alternative for yacc is bogus and remove it automatically. This just
seems more elegant.

--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/

[Debian Bug Importer (debzilla)]

Message-ID: <20050402234134.GB17974@rho>
Date: Sat, 2 Apr 2005 15:41:34 -0800
From: Chuan-kai Lin <email address hidden>
To: Michael Schmitz <email address hidden>
Cc: Bug 301075 <email address hidden>, Stephen R Marenka <email address hidden>,
 Gerfried Fuchs <email address hidden>, dpkg <email address hidden>
Subject: Re: Bug#301075: On #301075: bison and yacc alternatives

On Sat, Mar 26, 2005 at 11:25:42AM +0100, Michael Schmitz wrote:
> 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.

(Note: I trimmed m68k-build from the CC list)

Well, maybe "dangling alternative" is a better term than "dangling link"
(I use "dangling" to describe a reference whose destination does not
exist). I think dpkg maintains the alternatives database in
/var/lib/dpkg/alternatives, so merely removing the old byacc symlink in
/etc/alternatives or whatever does not do the trick. We need to do
"update-alternatives --remove" to completely remove the dangling
alternative.

What I was suggesting was that dpkg knows the following things:

 1. bison is trying to set up an alternative for yacc
 2. The yacc alternative is pointed to byacc
 3. The byacc program does not exist, and does not belong to any
    currently installed package

So in principle dpkg should be able to determine that the byacc
alternative for yacc is bogus and remove it automatically. This just
seems more elegant.

--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/

[Chuan-kai Lin (cklin)]

merge 301075 546490

[Chuan-kai Lin (cklin)]

retitle 301075 Stale dangling yacc alternatives from byacc