On Mon, 2009-01-26 at 16:36 +0000, Simo Sorce wrote: > On Mon, 2009-01-26 at 08:24 -0800, Jesse Keating wrote: > > On Mon, 2009-01-26 at 07:04 -0800, 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. > > > > Oh? And what stable reliable fast software virt do we have for ppc, > > ppc64, ia64, s390, and s390x? > > > > This is not likely to happen any time soon, so if we want to pick a > > kernel to run on the builders, it should be the same kernel we pick as > > the "lowest acceptable kernel" for the variety of targets we build for, > > which includes RHEL4. What happens if we pick up the 2.6.29 kernel and > > try to build RHEL4 packages on it, will they suddenly turn on > > functionality that can't possibly work on their intended target? > > It might, things like inotify comes to mind ... Which means there should be a configure-time option for --with-fsnotify=[inotify|dnotify] which will turn on the desired method explicitly. This stuff certainly shouldn't be autodetected by the configure script, or if it is, there should be a --with or --enable method to turn autodetection off and specify. That's the only way to ensure that as a package maintainer, you get hard failures at build time, not when users figure out stuff is broken and yell at you. Dan > > > I'm with Dan P.B., to obtain specific kernel level functionality it > > should be possible to override, so that you get a reliable reproducible > > build result. > > Sure, ideally Dan's arguments are perfectly true, but in practice, > sometimes, you don't even know where to look for (and by you I mean the > package maintainer, which is not always necessarily aware of the same > things upstream is), so the choice I think is: > - let's pretend we are in the ideal situation and risk shipping some > broken package > - let's assume upstream is not perfect so let's try to build on the > kernel we are going to ship packages with (or a recent enough version > anyway). > > It is also a problem of testing. > I, and most other developers build at most on something as old as an > updated Fedora 9, which has quite a recent kernel. The maintainer may > not even notice that there are problems when the package is built on > something as old as 2.6.9 > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
