[gentoo-dev] Re: Re: About linux-headers, making stages with catalyst

[Duncan <1i5t5.duncan@cox.net>]

Lluís Batlle i Rossell posted
<20041202110107.GA27739@vicerveza.homeunix.net>, excerpted below,  on Thu,
02 Dec 2004 12:01:07 +0100:

> What I've tried, while answering this email: I've tried using 2004.3 =>
> Still keeps on using 2.4 (there are no virtual definitions in 2004.3!)
> I've tried using default-linux/x86/2004.2/gcc34/2.6/ as profile => Even
> this way emerge still keeps on using 2.4
> I've tried changing the content of the virtuals in default-linux and
> default-linux/x86 => YES! Now it installs 2.6 headers.
> 
> But... Shouldn't the other tries work ??? At least, you say that about
> 2004.3, and the profile ....gcc34/2.6/ seems to have virtuals defined
> there.

OK, I see statements CG's statement that no x86 profile defaults to 2.6
headers for the virtuals, that he knows of, but you point out
profiles/default-linux/x86/2004.2/gcc34/2.6/, as I did.

Where a virtual is required, cascading profiles should read parent dirs
until they find the default, if it's not in the current profile dir. Thus,
the lack of a virtual definition file (or one not including all necessary
virtuals) shouldn't be alarming, as it should just look up-tree to fill
the requirement.

Because profiles/default-linux/x86/2004.3 has a 2.4 subdir, and I'd seen
discussion on the dev group/list on switching to 2.6 by default, I wrongly
concluded 2004.3 on x86 had done so.  It appears I was wrong.  As you
mention, there's no virtuals there, so it looks up-tree, to x86, where it
finds virtual/linux-sources defaults to sys-kernel/gentoo-sources.  That
covers the kernel virtual default, but not headers, so it looks up-tree
another notch, and finds them under default-linux, where
virtual/os-headers defaults to sys-kernel/linux-headers.  Note that it
/also/ mentions virtual/kernel, defaulting that to
sys-kernel/vanilla-sources.

This means that we have three separate virtuals provided.
virtual/os-headers defaults to the 2.4 series linux-headers.  However, we
have TWO DIFFERENT virtuals for kernel, virtual/kernel, and
virtual/linux-sources.  I'm GUESSING these should be one and the same, but
in any case, they both default to 2.4 series kernels altho different
branches of the series.  Which one (or both) would try to be merged would
therefore be dependent on which virtual individual packages called for.

I thought to simplify matters, quickly clarifying which /should/ be used,
by checking my arch, amd64.  However, the virtuals file there only ADDS to
the confusion, because instead of virtual/kernel pointing to a kernel, it
points to headers.  Of course the 2.4 kernel is depreciated on amd64, so
everything points to 2.6 versions, but both virtual/os-headers and
virtual/kernel point to sys-kernel/linux26-headers, while
virtual/linux-sources points to sys-kernel/gentoo-dev-sources.

Thus, virtual/kernel points to kernel sources in the one place, and only
kernel headers in another, which is certainly confusing me!

Anyway, back to x86, it indeed appears that
profiles/default-linux/x86/2004.2/gcc34/2.6 defaults to 2.6 versions of
both headers and kernel:
virtual/kernel                  sys-kernel/linux26-headers
virtual/os-headers              sys-kernel/linux26-headers
virtual/linux-sources           sys-kernel/gentoo-dev-sources

Hmm.. here too we have virtual/kernel pointing to headers, not sources, as
in amd64, but NOT as the default-linux virtuals file, where virtual/kernel
points to kernel sources instead of just kernel headers.

Anyway, it would seem that profiles/default-linux/x86/2004.2/gcc34/2.6
does what you want, PROVIDED you don't have any problems with gcc-3.4,
which is of course what the gcc34 refers to.  That sub-profile defines all
three virtuals, kernel, headers, and sources, to 2.6 defaults.

Note that catalyst most likely will *NOT* notice the changed profile,
unless you erase its previous tmp files.  I'm suspecting that's the other
problem you are experiencing now.  It has its config, and doesn't go
looking to change that, unless it disappears.  Therefore, after changing
your profile to the above 2004.2/gcc34/2.6, erase catalyst's temp files
and see if it recreates them using the desired 2.6 minimals, now.

Alternatively and the reason catalyst (again, presumably) works as it
does, is that it allows you to modify its temp file virtuals once it gets
past that point, thus allowing you to build a live-cd with a modified
profile, without affecting the build-system's profile.  Thus, instead of
erasing the tmp files so catalyst sees the new configuration, consider
editing the catalyst version directly instead.  However, I'd say do as
little editing here as possible, because it's possible tweaking one thing
there will cause something else problems.  An example would be tweaking
the headers virtual to linux26-headers, while leaving the kernel at 2.4
virtuals.  Gentoo's pre-built profiles should have those sort of
dependencies worked out, while editing them could cause problems due to
interlinking dependencies you weren't aware of when you did the editing. 
Thus, I'd recommend doing the above, change the system profile and erase
catalyst's tmp files so it regenerates from that, instead of manually
tweaking its profile, preventing potentially nasty surprises with
conflicting dependencies.

Also...  you mention changing the content of the virtuals.  You don't
mention specifically /where/ you changed that content, in the catalyst
temp files (OK), or directly in the portage tree itself (not so OK).  The
problem with changing it in the portage tree is that an emerge sync will
erase the changes you made (unless you have rsync-ignore set on that dir,
which creates problems of its own if Gentoo changes anything).  For a
one-shot catalyst build, and as long as you don't go doing an emerge sync
while it's running, you should be fine, but just be aware that emerge sync
/will/ erase changes you've made to the profiles in the portage tree
itself.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list