Julian Andres Klode wrote: > He wants you to include the debhelper commands, because autoconf > includes autoreconf and those are special dh_* commands for autoreconf. > But they could also be included in debhelper directly if you think this > would be better (and if joeyh shares this opinion).
Regarding including these commands in debhelper, I am uncertian because these commands would not be included in the default dh sequences, or the example rules files, and that would be a first -- currently every command in debhelper is included in the dh sequences and all except dh_auto_* are included in the longer example rules files. Adding an optional command to debhelper that likely does not do the right thing for a fairly large percentage of packages (my experience with running autoreconf and having it actually work, in the real world, is not exactly stellar) would be a departure. (It might make more sense to do this as one of debhelper's buildsystem classes.) I also have qualms about the implementation. Checksumming every file in the source tree will really suck for large source trees on slow architectures. Deleting any file that changes during a build could also be quite suprising behavior. Builds do sometimes change random files that it does not necessarily make sense to delete to revert out of the Debian diff. Is there really no better way to isolate autoreconf's changes to keep them out of the diff? Since debhelper already supports running configure and build in a temporary build directory, perhaps the simplifying assumption needs to be that if autoreconf is used, a build directory has to be used. (Note that dh_clean already removes autom4te.cache.) -- see shy jo
signature.asc
Description: Digital signature
