[Fedora-packaging] Re: Modifying upstream tarballs

[Axel Thimm]

On Wed, Jun 06, 2007 at 09:35:31AM +0200, Ralf Corsepius wrote:
> On Wed, 2007-06-06 at 08:55 +0200, Axel Thimm wrote:
> > On Wed, Jun 06, 2007 at 08:41:30AM +0200, Ralf Corsepius wrote:
> > > 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. 
> > 
> > In that case this means we would never be able to verify the pathces
> > at all, so an argument to not even let the package pass.
> No, it means "avoid running the autotools as part of building and patch
> instead to achieve deterministic builds for Fedora".

But the patches (to configure/Makefile.in) are supposedly generated in
a way that a typical Fedora system cannot reproduce, otherwise why not
generate them on the fly?

> > > > > 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".
> > 
> > Why? I see nothing in the design that implies that. In fact autotools
> > promote autorebuilds when a user modifies the sources of the generated
> > files.

> <sigh/> the autotools are code generators. (upstream) packagers are
> supposed to generate and package the generated files, while maintainers
> and installers are supposed not to touch them.

<ignoring uncomfortable sighing/>flex and yacc are also code
generators, so now we forbid the use of generating code? And what's
that --enable-maintainer-mode again? I guess autotools really disagree
with your POV.

There is absolutely no reason to forbid generating code whatsoever, on
the contrary, it's far beter to have small master source file changes
that can be reviewed and modified than to have patches to generated
files that one cannot really modify anymore. You lose part of the
openness in open source that way.

And again: If the derived source code changes are not reproducible
with Fedora tools, then the package is neither revieable, nor
maintainable in Fedora space at all.

> > > > 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.
> > 
> > If vendors like Red Hat need to modify libtool so that x86_64 is
> > covered then we need to use the vendor supplied autotools anyway, so
> > that's not a valid point.

> Not this topic again ;) Red Hat hacks libtool to work-around the bugs
> upstream libtool has not been able to fix for years ;)

So, you agree that using the vendor's autotools is a good thing, fine.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20070606/4ea69aaf/attachment.bin