Suggested packaging guideline: avoid running autoreconf

[Braden McDaniel]

On Sun, 2008-10-12 at 18:08 +0000, Kevin Kofler wrote: 
> Braden McDaniel <braden <at> endoframe.com> writes:
> >
> > On Sun, 2008-10-12 at 10:30 +0200, Nicolas Mailhot wrote:
> > > So if Oracle was freely redistributable tomorrow an rpm that just put
> > > the pre-generated Oracle files in the right place would be ok with you?
> > 
> > Getting to this question from what I said requires so many logical leaps
> > that it's not worth entertaining.
> 
> For you, all the questions you cannot answer are "not worth entertaining". :-/

That's a baseless assertion.  If you're really interested in my answer,
mail me off-list.  I'm not going to do it here because the question is
an obvious attempt at baiting with the goal of making this thread less
useful for coming to any sort of conclusion.

> > Are you claiming that by creating tarballs that are designed to be used
> > without having the autotools installed, the GNU build system is
> > impairing free software?
> 
> I'll let Nicolas answer that (as he's the one you asked), but generated files 
> definitely make it harder to exert your freedom to modify the software 
> (especially if you need the exact same versions of the autotools or you run 
> into trouble, which is what spawned your guideline and thus this discussion in 
> the first place) and I don't see what advantages they bring.
> 
> > "Ground" level is the upstream source provided by the developer.
> 
> But here what upstream includes is _not_ source, it's a generated file!

That distinction requires knowledge of the toolchain; it is deliberately
designed to be irrelevant to tarball users (of which rpmbuild is one).
And aside from exceptional situations, it is.

Guidelines aren't generally about exceptional situations.  They're about
articulating best practice for common situations.  Exceptional
situations frequently warrant... exceptions.

> If you define everything in the upstream tarball as "source", then Oracle's 
> binaries are "source" too, which is absurd.

What Oracle provides in their tarball is the source for an RPM generated
from that tarball.  That's a statement of fact, regardless of the form
the source takes or how it must (or must not) be transformed in the
process of creating the RPM.

You are welcome to find a more specific term for what you mean. "Source"
has a more general meaning than the one you're trying to apply.

> > Applying necessary patches to the build scripts in order to build
> > binaries does not make anything less free.
> 
> Sure, but forbidding us to patch the actual source code on the ground that 
> it "invites breakage" does.

Maybe you should reread the subject of this thread. I haven't advocated
"forbidding" anything.

> > If a packager wants to include changes to the build script sources in
> > the source RPM, I have absolutely no objection to that.  But applying
> > those changes as part of the build wins nothing and invites breakage.
> 
> Why should we jump through hoops to patch generated files and regularly update 
> the patches because they'll invariably break if we can just run autoreconf? It 
> is our (the individual package maintainers') problem to fix things if an 
> autotools update breaks them anyway!

Because it affects more than just you.  We won't have libtool2 in Fedora
10 because people do what you're advocating.  That means there are
upstream developers who will be waiting that much longer for it and not
taking care of problems upstream on their own.

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