On Tue, Jan 25, 2005 at 11:35:52AM +0000, David Woodhouse wrote: > On Tue, 2005-01-25 at 01:31 +0100, Axel Thimm wrote: > > That's a bit unrelated to this issue. The disttag is to indicate the > > build environment and to make packages build out of the same specfile > > on different build environments to align properly in rpm upgrade paths > > (same specfile, different build environments: make build environments > > of newer distros win). > > The build environment can make a _lot_ of difference. Nobody denies that. In the context of the disttag discussion, the disttag denotes the distribution which defines part of the build environment (the other part is the selection of active packages during build via BuildRequires) > In the case of bridge-utils, for example, you get entirely different > behaviour if sysfsutils happens to be installed when the package was > built. Without sysfsutils you get a package which doesn't work on > 2.4 kernels but which does work with 32-bit binaries on a 6-bit > kernel. With sysfsutils you get a 32-bit package which doesn't work > on 64-bit kernels. A 6-bit kernel? :) > Personally, I think the use of autotools should be banned in RPM > packaging. It adversely affects the reproducability. Agreed, patches to Makefile.am/configure.ac should also contain patches to the derived files. But you run into the problem of zero-time differences and make will consider recreating Makefile/configure if that timestamp is the same like the one of their sources and fail if no autotools are supplied in the build environment. An ugly hack is %patch0 -b .autotoolsmasterfiles sleep 2 %patch1 -b .autotoolsderivedfiles But we've gotten quite far off the main topic, I guess ;) -- Axel.Thimm at ATrpms.net
Attachment:
pgpFz7fOLdq58.pgp
Description: PGP signature
