[gentoo-dev] Re: [gentoo-core] Re: GLEP 26 -- Handling kernels with portage

[Duncan]

Nathaniel McCallum posted
<1083554281.28957.22.camel@××××××××××××××××××××.com>, excerpted below,  on
Sun, 02 May 2004 23:18:02 -0400:

>> > Yes.  This GLEP is basically a reworking of genkernel into portage.
>>
>> Yes you have seen the new work?  And no, you don't like it?  Or yes, you
>> like it and think it can help out?  Confused here... :)
>
> I do like the current process.  It just needs to be integrated into
> portage.  We need to be able to have easy building of binary kernel
> packages.  We need a one step build for users, rather than two step
> portage first then genkernel.
>
>> > Please understand it is bad design to have two build systems.

I'm just a Gentoo newbie, here, but this is my opinion, FWIW..

The fact that the kernel remains an exception to the normal build
process is a GOOD thing, IMO.  It accentuates its uniqueness and extreme
customizability (think the impossible to support with use flags thing),
and the fact that without it, you are dead-in-the-water.

I do NOT think that having all traces of a kernel, both the binary (and
modules) and its source tree removed with emerge unmerge would be a good
thing. Having to remove the pieces manually again accentuates the
differences and the fact that this is NOT just another ebuild on the
system.

I might as well have the same opinion about glibc as well, were it not so
standardized, due to the fact that a modern system is about as helpless
without it as it is without a bootable kernel.  However, it happens to be
close enough to monolithic (unlike the kernel with its modules), with few
enough fast-changing hardware dependencies (unlike the kernel) and a slow
enough significant upgrade cycle (unlike the kernel), that it's convenient
to do a source2binary ebuild for, and the advantages of doing it that way
outweigh the disadvantages (unlike the kernel, IMO).

People choose Gentoo because they like the customizability.  With
genkernel providing a solution for those that don't want to get /that/
into customizing, while still accentuating the fact that the kernel
/really/ /is/ different, I simply see no reason (other than the security
thing, definitely a valid point, but addressable on its own separately) to
integrate full kernel handling into portage, and overarching reasons NOT
to do so, including BOTH the difficulty of doing so, AND the benefits of
NOT doing so.

-- 
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@g.o mailing list