FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

LinkBack Thread Tools
Old 07-01-2008, 01:36 AM
Mart Raudsepp
Default Patching of Makefile.in and configure (eautoreconf calls)


Recently a big bunch of autotools related bugs were filed, of which
quite a few are quite obvious bugs that need to be fixed, but there are
a few of the kind that I can't agree with without given technical proof
it's a real problem.

So one of those is the "changes both autotools source and result" kind,
as seen from
https://bugs.gentoo.org/showdependencytree.cgi?id=226305&maxdepth=1&hide_r esolved=0

The short summary of most/all of those is that the ebuilds in question
are either patching or sed'ing not only Makefile.am and/or
configure.{in,ac}, but also Makefile.in and/or configure and it is
claimed that this is a "treatment [that] is usually reserved for a few
selected system packages that cannot have their autotool scripts
rebuilt.", with a vague claim that it _could_ cause
maintainermode-driven rebuild of the autotools results.

In most cases stopping the patching of Makefile.in and/or configure
involves removing that from the patch AND adding eautoreconf to the

The reason why I'm bringing this up is:

Do we really need to inflict the users with a long eautoreconf step,
when patching Makefile.in and configure alongisde Makefile.am and
configure.in is working just fine when done right, by my some years of
experience doing it once in a while where it's easy to provide a clean
patch for the autotools results?

Some reasoning from my side:

1) maintainer-mode driven rebuild is supposed to only happen if
a) the package defaults to maintainer mode in its configure.in; and
b) the autotools source is newer than the result, which can happen if
you _forget_ (as opposed to doing it, which the bugs are trying to
remove) to patch all results together with sources or you seriously
screw up the timestamps

2) eautoreconf means a considerable amount of extra time inflicted on
all _users_ of that package, without a clear technical reasoning why
that is really necessary

3) Other distributions happily provide a metric ton length of autotools
patches and it works just fine, albeit constrained to only package
maintainers in most cases

So I personally request to hold off with "fixing" these bugs without a
clear reasoning on the extra (every) Gentoo users resources taken, until
a technically valid reason is given, and I believe the burden of proof
should be on those that want the eautoreconf calls as to justify the
extra time and resource requirements involved.
You as the maintainer of an affected package are free to make your own
decision on this of course right now.

Though if you are hitting the maintainer mode rebuild ("missing --run"
in build.log without quotes or something), then it's a real bug and you
could probably just as well fix it by patching the Makefile.in or
configure that you forgot to patch when you patched Makefile.am or

Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

Thread Tools

All times are GMT. The time now is 06:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org