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

[Stuart Herbert <stuart@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 9107 bytes --]

On Monday 03 May 2004 16:15, Nathaniel McCallum wrote:
> Most of your questions below have already been answered in previous
> emails.  But we'll do it again.



> > If genkernel is broken - why not redo^H^H^Hfix genkernel instead?
>
> Why fix a build system that isn't part of portage when it could be,
> fairly easily integrated with portage.



> As I mentioned before, I left this fairly ambiguous on purpose.
> GentooInstaller will create a solution for this.  And if people like it,
> we can use it system-wide.

Until you address this ambiguity, I don't think this GLEP is safe to approve.

> This is no more "risk" than the current genkernel solution.  

Yes there is.  genkernel isn't the default way of installing a kernel.  In 
your emails and in your GLEP, you are stating that your proposal will become 
default behaviour.  That alone increases risk substantially.

> Besides, 
> you can either just make your own custom config or just trigger the use
> flag "-buildkernel" and do it the old fashioned way (you can even still
> use genkernel if you want).  We are talking about 100% backwards
> compatability.  I'm not removing anyone's choice.

It's not the choice I'm looking at.  It's the technical merits of your 
proposal.

> This will be dealt with in the same fashion as every other package in
> gentoo.  

> If you re-install it, it re-builds it and replaces the old 
> kernel.  

Unless I'm missing something here, isn't that going to leave a machine in an 
unbootable condition - seeing as you haven't designed a solution for updating 
the bootloader yet?

> emerge -C removes the kernel.  Its that simple.  

What happens if the kernel being removed is the kernel that is currently 
booted?

> Before you  
> complain that we should be able to have 2 kernels from the same tree,
> currently, genkernel doesn't support this without manually copying
> files.  So this GLEP does not take functionality away that exists with 
> genkernel.  

I don't care about genkernel ;-)  You started off your reply to me by saying 
that genkernel is only fit for the scrapheap - and now you're justifying your 
design by saying "well, it's just the same as genkernel"?

> If you want 2 kernels from the same tree, trigger the 
> "-buildkernel" use flag and just do it the old fashioned way.  > Or you 
> can also "emerge kernel" then manually move the files, then "emerge
> kernel" again, which would give you the desired results.  Either way
> this is the same exact functionality of genkernel.

Any well-configured Linux box has at least two kernels in the grub/lilo boot 
menu - and you'll often see advanced users keep a third entry in there.  
That's one entry for the new kernel, one entry for the last kernel (in case 
the new one didn't work), and one entry for a fallback kernel in case the 
first two get hosed up somehow.  These scheme was even supported directly by 
the kernel's 'make bzlilo' target, which would move kernels from the first 
slot to the second for you.

It would seem prudent (and good for our users) for any new default 
kernel-building solution to support such a scheme.

You haven't addressed 'emerge -u' at all in your reply.

> I have several revisions for the GLEP already, I'll try to put them all
> in.

> I answered this in another email.  All we are tracking is the config
> files themselves.  Users benefit by knowing when we make changes to
> kernel config files.  That is all I'm saying.

How do users benefit?  Seriously - I've no idea.  I've got four x86 machines 
in the house running Linux right now, and they all have unique kernel configs 
to support the differences in hardware.  I have trouble visualising how a 
'one config fits all' approach is going to work.

> Thats cause this is an initial draft.  However, it will be an external
> app.  You would call it manually, not as part of an ebuild/eclass.  The
> program is only needed if you don't want to use/can't use the supplied
> generic kernel config.

I don't understand how that will work.  if 'emerge <kernel-of-your-choice>' 
downloads, compiles, and installs your kernel automagically - all from the 
one command - where does the user get to run the external app?  Is the user 
going to run it before the kernel has been downloaded?  Is the user going to 
run the app after the kernel is installed?  There doesn't seem to be the 
possibility of the user running the app in between those two.

> > 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.
>
> It is not optional.  In stage 2 you either have to build the kernel
> ("buildkernel") or install sources ("-buildkernel").  Either way, you
> still have to  do stage 2.

I think your specification could be improved to make this clear and precise.

> The Stage 1 config app would provide for this.  Also, the Stage 1 app
> *DOES* configure the kernel the traditional way.  All it does is make
> sure kernel configs get copied to the right place.

That needs adding to the specification.

> > 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'm not sure what you mean by "kernel tarball".  

That's because your specification is vague on what will go into the tarball it 
says will be created in Stage 3.

> If you mean the 
> kernel-headers tarball, it gets removed if you do a emerge -C on the
> kernel.  It should probably be stored in /usr/src/.

Are you sure that keeping just the kernel headers is sufficient?  Have you 
performed tests to validate that you don't need any other files from the 
kernel in order to compile all of the third-party kernel modules currently in 
Portage?

> What happens if there is a security bug in a kernel (as there have been
> about 6 this year)?  genkernel can't notify you and portage can only
> upgrade your sources if you even used the sources from portage.  However
> in this GLEP system, "emerge --security" (when it gets implimented)
> would see a problem with your kernel, upgrade to the non-buggy kernel,
> build it, install it, and remove the old one (or warn you to remove it,
> whichever you prefer).

That is a good justification - you should add it to your GLEP.

> You mean warpzero and I and the members of the kernel team we spoke
> with.  <sarcasm> We all know how the kernel team knows nothing about
> kernels. </sarcasm>

Do I mean you and Warpzero?  Yes, because your names are on the document as 
authors.  But you haven't run this past johnm yet, and when it comes to 
kernel stuff him and gregkh are the two I'd put most faith in - and you've 
already seen Greg's response to your proposal ;-)

> I agree with this.  This was my first GLEP and as such, I missed some of
> the finer points.  

I think your aim's a bit further off than that ;-)

> However, its just a Proposal.  And if devs get this 
> much negative "your idea can't work" criticism from a simple GLEP, how
> do you think a Gentoo user would ever feel comfortable filing a GLEP
> (which is what they were intended for!).

I think any submitted proposal needs to be able to stand up to rigorous 
technical scrutiny.  If the idea has merit, or a groundswell of support, then 
the proposal will be the better for it.  If the idea is weak, flawed, or 
substantially incomplete - it's important we catch these things now before 
it's our users catching the results ;-)

A commonly-taught method of evaluating any proposal is de Bono's hats - where 
you look at a proposal from a specific viewpoint.  Look it up, and you'll see 
where I'm coming from.

> In the same way as not bashing a user for contributing an ebuild
> (remember, they could be a future contributer to Gentoo), we should,
> when faced with a GLEP, stop and think if there is anything posative
> about it, then try to come up with working scenarios.  Remember, devs
> are contributers to Gentoo.

Yes they are.  And you're right - anyone should be able to put forward a GLEP 
without fear.

> Thats also fine with me.  I don't want the GLEP approved right away, I
> just wanted it to be a sounding board for discussion to develop a good
> prototype.  Isn't that what a GLEP is for?

Maybe it would help if that discussion happened first, and the results were 
written up into a GLEP for approval.  That's happened in the past, and seems 
a successful model to reproduce.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
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
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]