On Sat, 21 Nov 2009, Resul Cetin wrote: > > 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.
> Yes, autohell is broken by design for distributions. Most packages will not > be > able to do a autoreconf - so you can use your README for whatever you want. Hmm? You have a halfway-done packaging, then. Yes, often there are bugs in the build system, which is your job to fix AS WELL. If you can't deal with the build system of something, don't package it. auto* are ugly, and I don't object to the autohell moniker, but there is no design problem for distros that require a full rebuild (which Debian __DOES__) per policy. The README is a bit outdated, there is some stuff there from 5 years ago when we didn't want rebuilds because it was hard on the slower buildds. This is not a problem anymore, even ARM is fast enough. I am aware of _one_ bug that gets in the way: autoreconf is dumb and can't do aclocal -I somedir. One works around that by calling the required autotools directly (which is much faster than autoreconf, anyway). > > 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. > CDBS tells use "don't do that... just copy config.guess and config.sub and > later restore everything". Then they're going (again) against the best practice. > CDBS can be asked to update libtool, autoconf, and automake files, but this > behavior is likely to break the build system and is STRONGLY discouraged Strongly discouraged by whom? The peanut gallery? You're encouraged to do it right. If you're not going to do it right, then it is best that you don't break it worse. How THAT became "you're STRONGLY discouraged to autoretool", I don't know. You build-dep on *tested* version of the autotools (there will be at least one, the one you're using!), and either call them directly or set the environment variables and call autoreconf. Nobody said you have to use the latest major release of the autotools, we fix them all when there's something that needs fixing, and the only ones that really cause problems (and thus require fixes and package rebuilds) are gettext (now autopoint) and libtool. If you're upstream, and you are not doing a botched up job, you don't have the autogenerated files in the VCS, and you have a script to retool it on the clean checkouts before generating release drops anyway. So it is not a problem to upstream authors that did it by the book, either. If you want this patch in, rename the util to something like dh_update_gnuconfig. -- "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
