Julian Gilbey wrote: > That makes some sense. But having DH_ALWAYS_EXCLUDE set in the > environment is surely even worse than having it in the rules file, > because it can affect builds in ways which are unreproducible on other > machines. See bug#352273 for an example of this.
Um, I don't really know what happened with #352273 but based on the svn
log, the rules file had DH_ALWAYS_EXCLUDE set to an invalid setting
which happened to work due to #349070, but which was never documented to
work; when I fixed #349070 in debhelper, the DH_ALWAYS_EXCLUDE setting
in the rules file stopped working. And it override my correct and
working DH_ALWAYS_EXCLUDE and broke things.
It's true that DH_ALWAYS_EXCLUDE can affect builds in ways that are
unreproducible on other machines, but only in two cases:
1. If the upstream tarball contains something that is excluded by
DH_ALWAYS_EXCLUDE. For example, a .svn directory. If this .svn
directory wanders into the package build directory, it will get
removed again if DH_ALWAYS_EXCLUDE is set and not otherwise.
2. If a package is built from svn and DH_ALWAYS_EXCLUDE is used, but
dpkg-buildpackage is not passed the options to make it exclude svn
directories from the generated tarball or diff, then a rebuild
from that broken source in an environment without DH_ALWAYS_EXCLUDE
can potentially behave differently.
#1 is a broken upstream source, and a maintainer would have to be very
careful anyway working with it. Probably either repackaging it or
passing -X.svn to any debhelper commands that might accidentially pick
up a .svn directory.
#2 is just a Debian maintainer mistake.
Note that in either case, something is broken even before
DH_ALWAYS_EXCLUDE starts to be used.
--
see shy jo
signature.asc
Description: Digital signature
