Suggested packaging guideline: avoid running autoreconf

[Braden McDaniel]

On Sun, 2008-10-12 at 02:25 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > But in any case, who really cares if the patch is big as long as the
> > changes are necessary and appropriate?
> 
> A big patch is a patch which touches many locations and that is a patch which 
> easily breaks when upstream makes any changes to their source code.

Sure, but we're talking about a patch that was generated from generated
code. It's easy enough to generate again.  Any changes to the source
files are no harder to integrate than they would be otherwise.

> > We can do without the strawman.
> 
> I don't see how comparing the situation to GCC and Binutils is a strawman, 
> they're all translators which take a source file as input and generate an 
> output file.

Well, I'm reasonably sure most persons reading this who are familiar
with the issues do see it.

> > > So how are the autotools different from GCC and Binutils?
> > 
> > Source packages produced by an autotools build are designed to be
> > buildable in the absence of the autotools themselves.  They are not
> > designed to be buildable without a compiler and POSIX environment.
> 
> That distinction is artificial, you're defining "building" to include the 
> compilation step for the code, but not the one for the build system.

I'm defining "building" to include whatever steps are *necessary* to
generate an RPM.  Rebuilding the build system scripts is not necessary
and can, in general, be avoided.  Avoiding this step is desirable
because undertaking it causes well-documented problems.

>  The only 
> difference I can see between the autotools and a compiler is that the 
> compiler's output is platform-specific (meaning you have to build from source 
> for portability), but take Java/OpenJDK/IcedTea as the example and that 
> distinction vanishes. Java binaries are "designed" to not need rebuilding at 
> all, so should we just ship them from binaries?

We seem to have drifted off into bizarro world.  Fedora's choice of how
to package Java impacts the issues here precisely nil.

You seem to have some notions of ideological purity about what packages
should contain and you're going to great argumentative lengths to ram
those notions down fedora-devel's collective throat.  What's missing
from your arguments is any characterization of a problem that gets
solved when we do it Your Way.

The guideline I've suggested (and apparently I'm not the first) is a
response to a real problem: stuff is broken and it wouldn't be broken if
the guideline had been followed.  You have not proposed an alternative
solution to the problem.  Rather, your position seems to be that the
breakage is simply acceptable.  Obviously, I disagree.  I think that
because it can be avoided, it should be.

> No matter how you spin the definitions, generated files are _not_ source code.
> 
> > Probably the reason there is no guideline treating all generated files
> > the same way is that doing so is a really dumb idea.
> 
> And why?

Indulging this question is beyond the scope of this thread.  The
guideline I'm proposing operates within the current ideological
framework, where patching files that happen to have been generated is
perfectly socially acceptable.  If you would like to propose a guideline
that changes that, feel free to do so; but please do have the courtesy
to pursue it in a new thread.

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