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

[Nathaniel McCallum]

On Mon, 2004-05-03 at 11:09 +0100, Stuart Herbert wrote:
> 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.

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.

> 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.

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.

>
> 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.

This is no more "risk" than the current genkernel solution.  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.

> 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.

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.  emerge -C removes the kernel.  Its that simple.  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.  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.


> 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 have several revisions for the GLEP already, I'll try to put them all
in.

>
> 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?

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.

> 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.

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.

>
> 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.

>
> 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).

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.

> 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".  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/.

> 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.

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).

According to your definition of "build system" every package in portage
has a build system.  Perhaps I should qualify a "meta-build" system.

> 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've already rethought this point.

> 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.

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>

> I think this GLEP needs significant revision before it's worth serious
> consideration.

I agree with this.  This was my first GLEP and as such, I missed some of
the finer points.  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!).

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.

> 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.

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?

Nathaniel


--
gentoo-dev@g.o mailing list