The notes for sys-kernel/linux-headers advise strongly that after emerging sys-kernel/linux-headers, you should re-emerge sys-libs/glibc, as otherwise new capabilities in the new linux-headers may not be available. Yet, if both sys-kernel/linux-headers and sys-libs/glibc have updates pending, the new sys-libs/glibc will be emerged *before* the new sys-kernel/linux-headers. If one is to follow the advisory, then after emerging both, one should promptly turn aroudn and emerge glibc *again*. Should this not be done the other way around? Should not sys-libs/glibc have a dependency upon sys-kernel/linux-headers, so that the new linux-headers are installed before, not after, the new glibc is built? This would save an unnecessary rebuild of glibc, a lengthy process. Reproducible: Always Steps to Reproduce: 1. emerge -pvu world when both sys-kernel/linux-headers and sys-libs/glibc have updates pending 2. observe the install order. 3. think "Hmmmm." Actual Results: glibc is emerged before the new linux-headers, requiring that glibc be immediately emerged *again* to take advantage of the new headers. Expected Results: If both linux-headers and glibc are to be updated, linux-headers should be emerged first to save the double rebuild of glibc.
ive punted the linux-headers log message as it does more harm than good package ordering is a PM issue. glibc already depends on linux-headers.
We can add a special case for virtual/os-headers, similar to one for virtual/libc from bug 303567.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9eff4fa6377b693f742fdc2bb3720a66375bc6ec
This is in 2.2_rc68, but I'll leave this bug open until it's in an unmasked version.
This is fixed in 2.1.9.
