Henrique de Moraes Holschuh wrote:
> 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.
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.
> 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.
CDBS tells use "don't do that... just copy config.guess and config.sub and
later restore everything".
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
Best regards,
Resul
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
