[Rpm-maint] [draft] spec file unification: autotools based projects

Stanislav Brabec sbrabec at suse.cz
Fri Jul 18 10:32:25 UTC 2008

Ralf Corsepius wrote:

> 1. We are not in different positions. You might not be aware about it,
> but Hans, Bill and I all package many packages in Fedora, comprising
> more than i386 and x86_64.
> 2. If what you claim was true, either the packages you are dealing with
> are of low quality or there is something very broken with the autotools
> integration of the distro you are using.

Autotools, distributions and processors are developing. Older autotools
cannot detect processors and systems, that did not exist in time of the
release. For example, old autotools were often not able to build shared
s390/s390x libraries. Working with engineering samples could make
autoreconf mandatory as well.

But if we are talking about unified packages for general use, skipping
of autoreconf seems to be acceptable.

It's possible to define and recommend use of %autotools_update macro,
which can have arbitrary contents defined by the vendor (e. g. empty).
If distributors feel the need to call autoreconf, it could be even
hidden into %configure.

Far the best solution would be encouraging software developers in using
of latest autotools.

> Only patching both sources and generated files guarantees deterministic
> behavior of building.

It may easily guarantee indeterministic behavior depending on order of
chunks in the patch, fraction of second, when the patch was applied,
file system time accuracy, disc cache size in memory and load of the

After spending one day of debugging of such issue, I would strongly
advice to never patch any auto-generated files.

Best Regards / S pozdravem,

Stanislav Brabec
software developer
SUSE LINUX, s. r. o.                          e-mail: sbrabec at suse.cz
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/

More information about the Rpm-maint mailing list