* Wookey <woo...@wookware.org> [150612 19:00]: > I would second the opinion that running dh-autoreconf by default is > something that should be expected to work. In practice it does work > except for old and languishing packages that have very old autofoo: > those need some updates. Often very simple ones, but in a few cases > deeper ones. See (https://wiki.debian.org/Autoreconf for useful info)
There is not only the situation with current autoconf/automake. The question is also if this is enabled what will happen in the future. While autoconf/automake got a very long way in no longer breaking packages every so often, the incompatible changes for tests is not so long ago (and happened after everyone already claimed those problems are a think from the past), that this cannot be ruled out to cause problems in the future. > So I would like to clarify whether there is a plan to do this in debhelper > for level 10 or not, as mooted in this bug > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744915#25 > > Maintainers (at least one) seem to be expecting it: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788321#20 > but perhaps that is premature? > > Is the situation 'yes, if someone sends patches', or 'yes, it's > underway', or 'maybe, sometime', or 'no never, it's a dumb idea' (or > something else)? In my personal opinion running autoreconf at build time is a derivitation from upstream at least on the same level as having some patch is. There is nothing inherently bad about derivating from upstream or applying patches, but I think there should be at least a good reason to. Then there is also the problem that as autoreconf is supposed to be run by people doing upstream work, there is no built-in mechanism to clean up after that. (There is make maintainer-clean, but last I looked it semantics were excplitely something like "whatever the maintainer thinks reasonable"). This leads those gross hacks dh-autorconf does to clean up. (And then even so strange "clean up" that does not clean but copy files back and forth last I looked). That said it might be a good idea to integrate some solution for this deeper with debhelper and at least warn in some cases when this is not used. (I guess looking for libtool or even usage of the 'canonical' variables (detectable by having guess.guess/config.sub)) Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org