On Mon, Jan 26, 2009 at 10:52:55AM -0500, Simo Sorce wrote: > On Mon, 2009-01-26 at 09:39 -0600, Mike McGrath wrote: > > On Mon, 26 Jan 2009, Ulrich Drepper wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Jakub Jelinek wrote: > > > >> The koji build boxes all run RHEL 5. Getting them upgraded to a not-yet- > > > >> released kernel seems unlikely. > > > > > > > > I know it is a pain, on the other hand it would really improve Fedora 11. > > > > > > Not only that. It is the only way to actually test what we are shipping. > > > > > > At least from glibc's POV (but indirectly from a much wider range) we > > > have to compile everything on the kernel we are shipping for the > > > release. Period. I know that the current build infrastructure doesn't > > > do this but this only means it has to change. We have virtualization > > > available, there is no excuse. > > > > > > > Ehh, I assure you if we don't change it... Fedora 11 will still ship so it > > doesn't "have to change". So someone needs to articulate, very precisely, > > what benefit investing time into our buildsystem, testing, release > > upgrading (Fedora is more expensive then RHEL), etc is going to have. > > Keep in mind we still can't even build epel on our normal buildsystem yet > > because of $PEOPLE_TIME > > > > What benefit will it have to our users? > > > > What benefit will it have to our developers? > > Mike, some features in our packages are determined at build time > depending on what kernel you build them on. Any case where a build probes for features in the build host's kernel, or runs just compiled binaries to probe for features, should always also have an explicit configure argument (or equivalent) to override the automatic logic. This is same problem you face with cross-compiling and places where people left out the 'ACTION-IF-CROSS-COMPILING' arg to the autoconf AC_TRY_RUN() macro. > So if the kernel is old enough, you might miss functionality in the > resulting packages, even more so if that package happens to be glibc I > think. If you want to guarentee functionality is built in, then an explicit configure arg can do this, without requiring that the build host be running the same kernel version as the eventual target host. This will give you much more reliably reproducable builds, because you won't find functionality suddenly turns itself off when rebuilt on a different system where someone doesn't know about the undocumented requirement on a particular host kernel version. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
