Started installing Gentoo on a blank computer, bootstrap.sh compiled glibc against kernel headers 2.4.19 (from the rc3 stage 1 tarball). (portage tree about is 5 hours old) Now "emerge -p system" output suggests it's trying to update kernel headers to 2.4.19-r1, but not recompiling glibc. The differences between 2.4.19 and 2.4.19-r1 are probably small enough to not run into problems, but shouldn't bootstrap.sh emerge kernel-headers first (glibc DOES depend on virtual/os-headers)? Steps to reproduce: 1. install stage1 tarball/sync portage tree/etc... 2. run bootstrap.sh 3. watch emerge -p output Actual results: glibc compiles against kernel headers from the stage tarball and kernel headers are updated in emerge system Expected results: Would save some time if kernel headers were installed BEFORE compiling glibc
Hmm, a good thought. I think what I'll do is add a small note to linux-headers-2.4.21 informing people it would be "wise" to re-merge glibc following the update of kernel headers. linux-headers-2.4.21 is current in unstable for most archs, and should go stable soon (hopefully), so it would be a good thing to add. The other solution is to make glibc depend on newer headers, and I'm unsure how this change would affect things. The newer header ebuilds utilize kernel.eclass, and thus when merging on a stage1 system, when you pull in linux-headers, the system attempts to merge about 20 other packages beforehand. Hopefully with the advent of new stages for the various archs, this will no longer be an issue, as I do not forsee any move to linux-headers-2.4.22 in the near future until the iputils issue is resolved. I'll go ahead and resolve this bug and add the note to linux-headers-2.4.21 and 2.4.22 ebuilds shortly.