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

[Nathaniel McCallum]

On Sun, 2004-05-02 at 20:56 -0700, Greg KH wrote:
> On Sun, May 02, 2004 at 10:04:35PM -0400, Nathaniel McCallum wrote:
> > The new glep is here: http://www.gentoo.org/proj/en/glep/glep-0026.html
>
> My formal objections:
>
> Basically the idea is nice, but I think the proposed solution is not
> correct.  Here is why I feel this way:
>
> > Stage 1 would be achieved through a seperate utility (perhaps like the
> > current genkernel). This utility would help the user configure the
> > kernel and any kernel/build related settings. This stage is optional
> > and would only be used if a person wanted a customized kernel
> > settings. One optional thought is to have this utility a part of the
> > base Gentoo system. That way there are less steps to make a custom
> > kernel.
>
> Why reinvent the wheel here?  The kernel has a _wonderful_ configuration
> system already.  It's provided in about 4 different interfaces at least
> (command line, ncurses, gtk, qt), and in library form.  Are you
> proposing hooking into that library to do the configuration?  If so,
> what is lacking in the current implementation that is needing another
> tool?

ok, perhaps the name is a little misleading.  The program itself doesn't
generate .config files, it just manages all aspects of creating them.
To actually create the file, it just calls "make menuconfig" or whatever
is appropriate.  However, what it does do is manage the config files
(not create them).  And by that I simply mean making sure they get
copied to the right place, etc...  This is not really much more than
genkernel does (if at all)

> > Stage 2 would be implimented through an eclass. This stage is not
> > optional. One would perform this step by typing "emerge kernel-name",
> > where "kernel-name" is the name of the kernel package you want to use
> > (ie. "gentoo-dev"). This package would have a "buildkernel" USE flag.
> > If the flag was not set, it would simply download and install sources
> > like we do currently. However, if the "buildkernel" flag is set,
> > portage will perform the following steps:
> >
> >	1. (as a dependency) download and install a tarball of "generic"
> >	   kernel config files.
>
> Is this really needed?  Don't we already do this today?
Yes, but:
	A. It isn't its own package.  Therefore, kernel configs cannot be
version tracked by users.  this is not good open development practice.
	B. The BUILD system isn't integrated into portage.

> Does this work?  As specified before, I really think you need the whole
> tree around in order to build external modules.  Now with 2.6, building
> those modules is a world easier (1 line makefile), and it works if you
> are not root (no write access necessary).  But again, all of this is
> already being addressed in the genkernel rewrite that is happening (and
> you can see it already in cvs.)

I'm pretty sure you don't need them all.  However, even if you do, with
this idea, you can just keep them tarballed, rather than unpacked.  This
still saves space.

>
> > Stage 3 would merely be an ebuild that constructs an initrd image for
> > either the running kernel or, lacking a running kernel, the newest
> > kernel installed (by version/date installed?). Initrd's can't be used
> > on all arches, so this ebuild can be keyword masked as appropriate.
> > The initrd package would also have a "bootsplash" USE flag (on x86,
> > maybe others) that would build in bootsplash support. Any non-default
> > actions desired by the user can be handled with the utility from Stage
> > 1.
>
> So "bootsplash" will be the only USE flag?  Why stop there?
>
> Oh, and initrd images are dead.  I predict that by the end of this year
> we will not be using them at all, as there is no need to (other distros
> are already proving this is possible.)  We also get a much more
> flexible, portable (works on all platforms) and cleaner implementation
> with initramfs, so that is what we will be moving to soon.  So your
> "initrd" options are pretty moot.

Fine, but people use them now, so we need to support them.  However,
with the abstraction of initrd into its own ebuild, when initrd's go by
the wayside, just make a new initramfs ebuild.

>
> > There are many advantages gained by this method:
> >
> >	1. Full arch support (GentooInstaller really could use this)
>
> We should fix genkernel to do this, if it doesn't already today.  There
> is no reason this should not be possible today without a total rework.

True, but why fix something that isn't integrated into portage?  Plus,
it is much easier to fix/maintain things when they are cleanly
abstracted.  This is not at all the case with genkernel.

> >	2. More consistent with the rest of portage (installs binaries
> >	   by building from source)
>
> True, it isn't as "clean"
>
> >	3. Better user experience
>
> You forgot "mom and apple pie" here too :)

You joke, but think about being able to manage kernels from porthole
(http://porthole.sf.net)? or another application?  It really does add to
better user experience.

> >	4. More flexability (genkernel forces building of initrd on x86)
>
> I've already outlined the issues of initrd going away, so this isn't an
> issue.

Even if initrd DOES go away, all the more reason to integrate into
portage.  I mean, you'll be rewriting over half of genkernel anyway!

Better to just abstract the stuff first...

> >	5. Don't have to store full kernel sources (each source tree is
> >	   ~200MB unpacked)
>
> You don't have to that today if you don't want to build any other kernel
> modules that are outside of the main kernel tree.  I have a number of
> boxes set up this way right now.  In fact, those boxes do not even have
> a single kernel package on them at all, I just rolled my own and
> installed it.  Once of the niceties of Gentoo is that you do not have to
> install a Gentoo kernel in order to have a working box (which for my
> job, is a very good thing.)

But try installing a kernel, building it, then emerge -C'ing it.  You
are left with all the extra junk behind.  YES, I know that this is the
correct behavior, and I agree.  However, it is sloppy.  Adding the
building into portage cleans that up while still maintaining correct
behavior.


> >	6. Creates the ability to make binary kernel packages for fast
> >	   installs (think GRP kernel)
>
> I see no where in your proposal for how this will be accomplished.  In
> fact, this is the first place in the GLEP that "binary kernel packages"
> are even mentioned.  Please either add the description of how you are
> going to do this to the SPECIFICATION portion of the document, or take
> it out of the RATIONAL portion.

I would think this is rather self evident.  To over-simplify, when you
use the "-b" option with emerge it makes a tarball of all the files you
install and appends the ebuild to the end of the file.  If building is
handled by portage, and it is "installing" not source files but binary
files, the "-b" option will make a tarball of the kernel binary, the
modules, and the kernel-headers/sources.  all you have to do to install
this kernel now is an "emerge -k kernel".  This is the same exact
fashion as all other packages.  And thus, I don't think it needs
clarification.

>
> >	7. A seperate package for "generic" kernel config files gives us
> >	better version tracking
>
> "better version tracking"?  What do you mean here?  Kernel config files
> can not be kept identical across 2 different kernel versions.  And they
> are not supposed to be.  They are a vital portion of the kernel version
> itself and can not be split out.  To think otherwise is to not fully
> understand the kernel build process.
>
> Also, is this a problem today?  I have not seen issues related to this
> in the past, have you?  Are there any bugs you can point us at that
> would show how this would help out?

OK, the way genkernel currently does this is by storing a "template"
config file for each major kernel version (ie. 2.4, 2.6, etc).  When
genkernel decides to use the "default config", it copies the "template"
config to the source directory and does a "yes | make oldconfig".  I'm
not proposing anything different than this.  I'm MOSTLY talking about a
restructuring of genkernel, NOT a start from scratch.  The restructuring
abstracts the config from the kernel building from the initrd/initramfs.
This is cleaner, and in the process, gives us portage integration.

By version tracking I simply mean this: I have a tarball of "generic"
kernel configs.  Lets call it "sys-kernel/generic-kernel-configs" for
fun.  The first time I release them it is version 1.0.  If I find a bug
and fix it, we now have version 1.1.  This lets our users know when
something has changed in the kernel config.  Its just more "open" and
that is really all I meant by it.

At this point I'd also like to say that this GLEP is a proposal.  It is
in "draft" stage.  So by all means, propose ideas.  But don't just say
"what we are doing now is great" because, even though it is, it could be
better.  That is all I'm pointing out.

Nathaniel


--
gentoo-dev@g.o mailing list