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

[Stuart Herbert]

On Monday 03 May 2004 03:04, Nathaniel McCallum wrote:
> The new glep is here: http://www.gentoo.org/proj/en/glep/glep-0026.html
>
> Nathaniel

Hi Nathaniel,

I'm trying to understand the problem that this GLEP is trying to solve.  To be 
honest, the current wording comes across more like a solution looking for a 
problem.

If genkernel is broken - why not redo^H^H^Hfix genkernel instead?

Your GLEP totally fails to address how your binary kernel image is going to 
end up in the lilo/grub boot menu.  It also fails to address dealing 
with /boot filesystems.

It doesn't address how you're going to manage any risks that this process will 
introduce.  For example, there must be a significant risk that your 'generic' 
kernel config will build a kernel that renders the user's machine unbootable.

One of the justifications for doing this work is "2. More consistent with the 
rest of portage".  However, your GLEP doesn't fully define how the initial 
install will work - and it completely fails to address how emerge -u and 
emerge -C will be delt with.  It also doesn't address how re-installing the 
same version of the kernel will be handled.  I've just been through this with 
GLEP 11, and based on my experience I'd recommend that your GLEP is not 
approved until you've credibly addressed these areas.  That's nothing against 
your proposal in particular - I think it should be a standard point in the 
GLEP reviewing process.

I completely fail to understand your Rationale 7.  What does a generic kernel 
config file allow you to version track better?  What are you version 
tracking?  The config itself?  Who will benefit from that, and how?

Your GLEP doesn't specify how the utility described in stage 1 will be 
executed.  Will it be called from the eclass?  If so, what USE flag will be 
used to make it optional?  There's no description of how this utility would 
work.

The GLEP says that Stage 2 is not optional - but then goes on to say that this 
stage can be skipped by USE=-buildkernel.  This part of the Specification is 
broken.

There's no provision in the GLEP for your Stage 2 to pick up existing custom 
settings created outside of the utility mentioned in Stage 1 (ie, a kernel 
configured the traditional way).  

There's no justification given for creating this kernel tarball.  The 
specification does not state where this tarball will be stored, or how it 
will be removed from the system when no longer required.

I don't think your main case for GLEP 26 is well-argued.  Actually, I don't 
think you've put up any argument at all.  For a start, there are *three* 
build systems - not two.  You forgot the kernel's own build system.  Are you 
planning on replacing that too?  You haven't made the case for why Portage 
and genkernel are competing.  You haven't made the case for why any 
competition in this area is necessarily bad.

Why would it be good for backwards-compatibility to have your stage 1 utility 
called genkernel?  Surely the functionality of the two is so different that 
it would mislead and confuse the very users this process is trying to help?

I think the authors of this GLEP, and those they have taken advice from, have 
seriously underestimated the complexity that this proposal requires, and at 
this stage have a proposal that is either badly thought out, badly documented 
- or both.

I think this GLEP needs significant revision before it's worth serious 
consideration.  Also, because of the unique nature of the kernel, I think we 
should insist on a working prototype that demonstrates how the process will 
work before the GLEP is approved.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@g.o
Gentoo Developer                                       http://www.gentoo.org/
Missed the php|cruise?             http://dev.gentoo.org/~stuart/cruise-2004/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--