On Wed, 18 Nov 2009, Resul Cetin wrote: > > package exists to build debian binary packages. I consider the entire > > "revert" stuff useless complexity. > So that the next rebuild notices a change in the config.guess/.sub? Forget > it.
Did you even read the README? I don't think it avocates leaking crap to diffs. In fact, I recall it recommends rm -f config.sub config.guess in debian/rules' clean target. Are you aware that any proper Debian package has to trash upstream's autoconf/autoheader/libtool/automake/gettext/autopoint -generated files, and "autoreconf" everything using the Debian versions of autotools? This is the recommended way of doing things, so that the backage builds with appropriate versions of the autotools engines, AND so that a binNMU is enough to propagate fixes, e.g., in libtool to the packages. Yes, a big lot of packages don't do the above, which is not optimal, but we deal with it through mass bug filings when required (argh). If a DD follows the "debian/rules clean should give you the upstream tarball" school, that means he would need a fully separate build-tree, where he copy everything of interest there, modify, patch, and build. This doesn't mix well with dpkg-managed patches. The proposed dh_ script is not optimal for this scenario, it needs to have (optional?) parameters to tell it where to install the config.* files. If the DD doesn't follow that school (most don't, AFAIK), he has to rm -f all autogenerated files in debian/rules' clean target or they will leak to the diff anyway. At that point the tree needs special steps to get back to the "./configure ; make ; make install" state anyway, and rm -f config.sub/guess is easier. If the DD wants things half-way, i.e. have the tree buildable upstream' style, he is going to screw us over (the mass bugfilling) OR leak autotools crap to the diff. There is no possible middle-ground. Now, you see why I think the proposed script is not that useful? > The patch does the only sane thing possible. I don't agree (see above). But even if I do include it, it will not be under the dh_autotools name. It doesn't do even HALF of what it would have to do to deserve that name. Thus, the dh_autotools name is vetoed. Please rename it to dh_update_gnuconfig or something like that. CDBS does a lot more setup to ease autotools usage, maybe it would be a good idea to look at what it does, and try to translate a more complete set of functionality for a "dh_autotools"? That will either need some hooking to debhelper internals, or two separate tools, one for clean, the other for pre-config setup. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
