Bug#213524: automake: serious breakage with new install-info behaviour
On Sun, 26 Oct 2003, Santiago Vila wrote:
> Adam Heath wrote:
> > I'm not fixing this bug. automake should not be doing what it is
> > doing, as it was bound to fail. automake was depending on questionable,
> > and wrong behaviour, and it's not surprising it died as it has.
>
> Yes, we all agree on that, but the issue here is not to blame dpkg or
> automake but instead saving the sarge release from a very great breakage.
>
> We all agree that this is an automake bug and not a dpkg bug, but if
> we release sarge in this way, there will be a lot of packages that,
> when built from source, will not yield the "same" binary that we
> distribute in the archive. This is some sort of FTBFS, since source
> and binary do not match.
Better to fix the bugs now, before release, then have them hang around after.
For instance, if we delay this 'fix' until after sarge is release, we will
*still* have the problem then. There will be backed in sarge that *will not
build* when sarge+1 is released.
> What we are asking you is that you keep the old behaviour of install-info
> (even if we all agree it's the wrong behaviour) *only* for the sarge release,
> to prevent a lot of breakage in a lot of other packages (which are buggy
> anyway, I'm not proposing that we do not fix them as well).
>
> The day sarge is released, install-info could be modified again in
> testing and unstable to do what it should do (the current behaviour in
> unstable).
>
> This is not very different from enabling dpkg --force-overwrite by default
> in stable and disabling it in unstable, or what coreutils maintainer
> has done with the POSIX stuff by allowing "chown user.group" in sarge
> for now.
And I'm not going to enable that either.
As for coreutils, that's different. Admin scripts make use of the user.group
syntax. I highly doubt any make use of where --version goes.
As for fixing automake, just make a new upload of the various automakes, that
no longer have the issue, and place all them into sarge. Users can then just
rerun automake on their sources.
> If we want to release a sarge with the current install-info that it's
> not completely broken as far as binaries which match sources is concerned,
> we should verify that none of the current source packages in the
> archive yields a package containing /usr/share/info/dir when compiled
> using current tools. Can you imagine what a huge task is this, or even
> whether or not we will be able to do that?
Bugs should be fixed, not masked over or hidden.
I have *never* liked that --force-overwrite is enabled. Ever. It showcased
a problem with our tools.
I mean, we *absolutely* know what was in the previous stable. All versions of
it. We can be *absolutely* certain what files are there. Why can't we write
file overlap detection?
Reply to: