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?
