Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
On Tue, Dec 24, 2013 at 02:00:05PM +0000, Wookey wrote:
> Every new port involves hundred of patches to packages updating
> config.sub and config.guess so that packages build on the new arch.
[...]
> Is there any reason not to make this a default behaviour? I am not aware
> of this ever causing a problem with package builds, even where the
> config.{sub,guess} being replaced are very old.
Generally agreed, although I believe you have to be somewhat careful
when using it in combination with dh-autoreconf; this should be solvable
just by making sure things are built and cleaned in the proper order, I
think.
Mostly the patches I've sent for these things have either been ignored
until NMUed, or applied without complaint, but I've found that I've
ended up in arguments with a small number of maintainers who have (IMO)
irrational objections to updating config.guess/sub automatically,
generally based on either confusing it with autoreconf and incorrectly
believing that it has similar levels of breakage, or hanging onto a
more-than-15-year-old grudge about GNU config triplet changes in the
dawn of time. I'd be happy to take this to the TC if necessary, but
it's relatively minor and I figure we have enough to do. :-)
I would have more sympathy for the position of the few people who are
reluctant to do this if they could show me a single example in the last
ten years of config.guess/sub updates breaking anything at all, ever.
One thing, though, is that debhelper will probably only sanely be able
to do this update when using at least some parts of debhelper 7 (dh
itself or *maybe* dh_auto_configure), so I suspect that any auto-update
will still only cover a subset of the archive.
> This is much more conservative than doing a full autoreconf, which
> regularly does break things, and would be a controversial thing to do
> by default.
Yes, although note that the upcoming ppc64el port will require a full
autoreconf for anything that uses libtool, because it requires a libtool
patch that hasn't yet been part of a stable libtool release and is
generally very poorly deployed in the generated autotools files shipped
in upstream packages. I've been sending rather a lot of patches to
convert things to dh-autoreconf over the last couple of weeks. It is,
IMO, clearly the better path (both for long-term porting needs and in
the ethical sense that it makes it easier for users to change the true
source code for the build system), but it does require a bit more
knowledge and effort from maintainers.
It is true, though, that *most* ports can get by without this, and just
need widespread config.guess/sub updates.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: