Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 25836 - base system: kernel headers / glibc inconsistency
Summary: base system: kernel headers / glibc inconsistency
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Please assign to toolchain
URL:
Whiteboard:
Keywords:
Depends on: 27636
Blocks:
  Show dependency tree
 
Reported: 2003-08-03 15:39 UTC by Reporter
Modified: 2003-10-30 14:59 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Reporter 2003-08-03 15:39:33 UTC
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
Comment 1 Joshua Kinard gentoo-dev 2003-10-30 14:59:56 UTC
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.