[Fedora-packaging] PackagingDrafts/AutoConf

[Ralf Corsepius]

On Wed, 2008-10-15 at 02:57 -0400, Braden McDaniel wrote:
> 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)?
Yes, it would require preserving timestamps and/or touching files.

Preserving timestamps isn't easily doable with rpm (c.f. option -T in
man patch), but touching often is very simple. Depending on the
complexity of a patch and the complexity of a package, normally reduces
to very few touch'es (working principle: set the time stamps of modified
files to that of an unmodified file at the root of auto*tools
dependency)

e.g. often a
touch -r aclocal.m4 configure.*
or similar after applying a patch works.


> > >   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.

Agreed.

>   I
> don't know if it can be relied upon to check timestamps and regenerate
> only what needs regenerating.
AFAICT, older autoreconf's had been problematic, but newer ones seem to
work quite well with packages having been developed with modern
autotools - At least, I haven't see a breakage for while a while.

>   I wouldn't want someone who needs to
> patch Makefile.[am/in] to wind up regenerating configure--that's silly.
It's not that silly, because newer automake/aclocal's require newer
autoconf's.

The effects only show on rare occasions, nevertheless they occasionally
show. However, more often you encounter cases, where regenerating
Makefile.am's with new automakes breaks Makefile.ins, which had been
developed with old automakes.

> 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.
:)

Ralf