[Fedora-packaging] Re: Modifying upstream tarballs

Ralf Corsepius rc040203 at freenet.de
Wed Jun 6 06:41:30 UTC 2007


On Wed, 2007-06-06 at 07:42 +0200, Axel Thimm wrote:
> On Tue, Jun 05, 2007 at 09:04:01PM +0200, Ralf Corsepius wrote:
> > On Tue, 2007-06-05 at 12:40 -0500, Rex Dieter wrote:
> > > Ville Skyttä wrote:
> > > 
> > > > I think running autotools locally before re-rolling the modified tarball 
> > > > instead of doing the absolute minimum changes would be ok in this case, as 
> > > > long as things are scripted/documented.
> 
> I've never run into a package whose autotools was not supported in some
> version in Fedora, and if that kind of package does exist, then it is
> even harder to redo the steps, so we will lose reproducablity of
> sources.
> 
> > > I'm uncomfortable with that, and prefer the consistency/reproducibility 
> > > of running autotools at buildtime, but that's just me.
> > This approach is the guaranteed way to ruin, because
> > 
> > 1. The autotools are not supposed to be run at built time.
> 
> Unless configure.ac/Makefile.ams are patched.
Then patch the generated files, too. 

> > 2. Many older package configurations do not work with recent autotools
> > and break in often subtile ways if you run newer autotools on them.
> 
> That's why we have tons of auto*<version> packages to cover all cases.
Well, we have some RH-patched versions around, but we don't necessarily
have the versions around the original authors used. The might have been
using differently patched versions originating from other vendors or
even custom versions.

So, even using the RH-patched versions resembling to the original
versions isn't guaranteed to work. 

> > 3. There is nothing reliable in running the autotools at buildtime.
> 
> Looks like a repetition of point 1. :)
1. was poorly phrased ;) It should have been "the autotools are not
designed to be run at buildtime".

> Autotools have been known to provide deterministic results just like
> any other software. ;)
If people were using vanilla versions and if vendors would should
vanilla versions, yes.

> > Finally, it's not hard not add magic to configurations in such a way
> > they don't re-run the autotools.
> 
> Can you elaborate what this means when configure.ac/Makefile.am have
> been modified?

Also patch the generated files and adjust timestamps on generated and
source files. What to do exactly depends on the version of auto*tools
being used and on a configuration's details.

>  You must either redo the autotooling or ship a second
> patch that is applied after a (u)sleep to the first patch.
Nah, adjust the time stamps after applying the patches:

E.g. in one real-world case I maintain
touch -r configure.in config.h.in
does the job.

What to do exactly depends on a package's details (check the a package's
toplevel Makefile.in).

The trick is to adjust timestamps between sources (configure.{in,ac},
Makefile.am, and generated files (configure, aclocal.m4, Makefile.in,
etc.), using the source files as time-stamp reference files.

Ralf






More information about the packaging mailing list