[Fedora-packaging] PackagingDrafts/AutoConf

[Braden McDaniel]

On Wed, 2008-10-15 at 07:48 +0200, Ralf Corsepius wrote:
> On Wed, 2008-10-15 at 01:19 -0400, Braden McDaniel wrote:
> > On Tue, 2008-10-14 at 10:50 -0400, Tom "spot" Callaway wrote:
> > > On Sun, 2008-10-12 at 01:16 -0400, Braden McDaniel wrote:
> > > > I would like to make some progress on this:
> > > > 
> > > >         <http://fedoraproject.org/wiki/PackagingDrafts/AutoConf>
> > > > 
> > > > The goal, I think, is incorporation of something like this into Fedora's
> > > > Packaging Guidelines. I'm told this is the place to come.
> > > 
> > > This is the right place... do you feel that Draft is ready for us to
> > > consider it for inclusion in the Packaging Guidelines as is?
> > 
> > After some discussion on fedora-devel, I'd say "not yet".
> ACK.
> 
> > While I do think it's appropriate to steer packagers toward patching
> > configure and Makefile.in for trivial cases, I'm coming around to the
> > notion that for more complex cases the prose should restrict itself to
> > being informational.
> Not ACK. Patching auto-tools sources and generated files is always
> preferred, because only this guarantees deterministic builds.

"and"? If you're patching both the sources *and* the generated files,
couldn't you wind up in a situation where the source is newer than the
generated files (i.e., the source gets patched after the generated
file)?  If that happens, "make" calls the tools to regenerated stuff and
you've just outsmarted yourself.  This subtlety is avoidable with
multiple different patches (applied in the correct order), of course;
but for the purpose of a guideline, I'm inclined not to recommend
patching both.

> If I were to decide, I would ban all calls to the autotools inside of
> specs, unfortunately, many people do not want to accept this thought,
> and consider running the autotools inside of *specs to be superior.

I agree, but I'm inclined to take a pragmatic approach where a package
maintainer might need to do extensive patching to the build scripts. I
think it's an exceptional case, but I don't want to make that guy's life
hell.

OTOH, I would certainly want the guideline to make clear that the
autotools should not be run just for the hell of it (i.e., because the
package maintainer wants to make sure the "latest stuff" gets used).

> It's not a secret, I consider this practice to be "naive maintainers
> outsmarting themselves" and these people to be exposing Fedora packages
> to risks.
> 
> Unfortunately, I am preaching at walls :)

We're on the same page ideologically.  But I want to find something that
will be palatable to most packagers while addressing the most glaring
potential for breakage.

> >   But I continue to think that certain invocations
> > of the tools should be practically forbidden.  ("autoreconf -f", I'm
> > looking at you.)
> 
> autoreconf is just a wrapper aiming at automating invocations of the
> tools underneath and at replacing the plethora of (often broken)
> "bootstrap.sh / autogen.sh etc." scripts.
> 
> So, if you intend to ban autoreconf, you should be consequent and ban
> all calls to the autotools.

My motivation for banning autoreconf would be that it is a shotgun.  I
don't know if it can be relied upon to check timestamps and regenerate
only what needs regenerating.  I wouldn't want someone who needs to
patch Makefile.[am/in] to wind up regenerating configure--that's silly.

If it *can* be relied upon to respect timestamps, then I have no more
quarrel with its use than I have with invoking any of the autotools
directly.  (Which is not to say that I have no quarrel with it.)

> If you are aiming at banning "autoreconf -f" (Note: -f), then you are
> right, "autoreconf -f" is harmful in many cases.

I'd say every case.

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