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. > 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. > 3. There is nothing reliable in running the autotools at buildtime. Looks like a repetition of point 1. :) Autotools have been known to provide deterministic results just like any other software. ;) > 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? You must either redo the autotooling or ship a second patch that is applied after a (u)sleep to the first patch. And reviewing a patch to configure/Makefile.in to verify it is indeed the derived patch from configure.ac/Makefile.am is no fun. -- Axel.Thimm at ATrpms.net
Attachment:
pgpqrb0KaiDlb.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
