Bug#213524: automake: serious breakage with new install-info behaviour
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.
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.
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?
Reply to: