Suggested packaging guideline: avoid running autoreconf

Braden McDaniel braden at endoframe.com
Sun Oct 12 04:04:13 UTC 2008


On Sun, 2008-10-12 at 01:27 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > The premise that the patch you apply as part of the specfile build is
> > the same one you should be submitting upstream is faulty.
> [snip]
> > Won't happen if you're only patching configure and Makefile.in, as you
> > should.
> 
> If your original change was on configure.ac and Makefile.am and you're only 
> shipping the patch for the generated configure and Makefile.in, you're 
> violating the GPL.

Please actually read the licenses for the tools before making such
inflammatory accusations.  You're completely wrong.

Neither autoconf nor automake place restrictions on the use of their
output.  While a project could conceivably apply the GPL to its
configure and Makefile.in(s), I've never seen a project do that.  It
would be, to say the least, unusual.

> > There can be all sorts of reasons for that.  But packagers faced with an
> > uncooperative upstream need to learn to live with the reality that their
> > package will be harder to maintain.  It should not be considered
> > acceptable behavior for packagers to punt and create work for the poor
> > guy who drew the short straw for the libtool (or whatever, as the case
> > may be) upgrade.
> 
> I don't see why this should be handled any differently from a new GCC version, 
> where the GCC maintainer will help with actual GCC bugs and in with diagnosing 
> some non-obvious problems, and also do a mass rebuild and report the results, 
> but ultimately it's the maintainer of the affected package who is responsible 
> for getting it to build with the latest GCC.

It's different because such a situation is rather easy to avoid.

> Still, it should be up to the maintainer to decide on the tradeoff (i.e. on 
> what's more work: forward-porting the patch for the generated files or getting 
> the package to build with newer libtool/auto*/... versions), and the autotools 
> maintainers should expect their new versions to break things and so handle them 
> like new GCC versions.

There's no reason for the autotools maintainers to expect their releases
to break clients of autotools source packages because those packages are
designed to be usable without the autotools themselves.  Clients who opt
to ignore or subvert this functionality do so at their own risk.  It
becomes a problem for everyone else--and thus justifies a
guideline--when the risk incurred poses an impediment to the progress of
Fedora in general (in this particular case, upgrading libtool).

> > > (This is exactly why generated files in source tarballs are a major PITA
> > > and the autotools are broken by design.)
> > 
> > Yes, this sort of whining is *really* productive.
> 
> It's not whining, it's a statement of fact.

Asserting that the autotools are "broken by design" because their use
results in the distribution of generated files is simply your opinion.
The notion that source distributions should not include generated files
is certainly not something that is generally accepted as fact.  In fact,
the number of packages that do include generated files suggests that
your viewpoint is unorthodox.  The inability to differentiate dogmatic
opinion from objective fact is a characteristic of zealotry.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>





More information about the fedora-devel-list mailing list