kernel-devel: should yum install, not update?

Axel Thimm Axel.Thimm at ATrpms.net
Tue Jan 25 12:48:59 UTC 2005


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050125/f3875f0f/attachment.sig>


More information about the fedora-devel-list mailing list