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

[Nathaniel McCallum]

On Sun, 2004-05-02 at 20:06 -0700, Greg KH wrote:
> On Sun, May 02, 2004 at 10:54:26PM -0400, Nathaniel McCallum wrote:
> > On Sun, 2004-05-02 at 19:45 -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
> > >
> > > Hm, did you consult the current kernel developers/maintainers/packagers
> > > before creating this?  At first glance I see a number of issues that
> > > would make this completely impractical and impossible to implement.
> > Yes.  Actually, a lot of people have talked about it.
>
> Ok, did johnm sign off on this?  As he is the current Gentoo kernel
> maintainer I would expect you would have run this by him.

I sent him an email.  He hasn't replied yet.  However, plasmaroo and I
spoke extensively about this.

> Do you want me to outline my objections to this proposal here, or is
> there some other place to do it?

Here is fine.

> > > Also, have you taken a look at the current genkernel work being done for
> > > 2.6?  It probably resolves lots of the issues it sounds like you
> > > currently have with the kernel packaging process.
> >
> > 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.
>
> Ivory towers are over that-a-way.  Real world is here :)  Come on, the
> build system for the kernel is just so much more complex than what the
> current portage system can even begin to support, based on what you are
> trying to propose.

Not at all or in any sense is this true.  People 5 years ago thought
something like portage would never work.  In the original version of
GLIS (before genkernel even existed) I built a fully functinal automated
building system.  And, btw, both it an genkernel were written in bash.
There is nothing stoping a re-working of genkernel's code (in BASH) into
eclasses and ebuilds (ALSO in BASH).

I'm not living in the ivory tower.  Abstraction is simply good code.

>
> Also, please realize that the 2.6 kernel build process is infinitely
> better than the 2.4 one, and based on it, a number of your listed
> objections and proposals are pretty moot.

Like binary packaging support?  Being able to keep around just the
kernel headers?  A single API for all package building?  Actually, none
of the reasons for the GLEP are solved by the 2.6 kernel build process
(although it is bettter).


> > Two build systems means one of them has a bug (ie doesn't support
> > needed types of building).
>
> Could you perhaps outline your current objections and problems with the
> current build system, contrast it with the currently being worked on
> changes to that build system, and maybe we can work from there?

Please read the GLEP carefully.  Everything is outlined in there.

>
> > > I do find the idea of packaging up a "binary" kernel a bit interesting,
> > > but who is going to be doing that packaging?  And who is going to
> > > mediate the zillion different "but why don't you select this kernel
> > > option instead" requests that will be caused by such a package?  :)
> >
> > Users can do their own packageing, then can also supply their own binary
> > kernels.
>
> Do we allow this with the current -bin packages already?  I might be
> mistaken, but I didn't think we did for some reason...

-bin has nothing to do with kernels.  Besides, -bin packages have to be
made by hand.  I'm talking about automation.

> > This is very much desireable for enterprise users (think clusters
> > especially) and for Gentoo Installer.  We will not be accepting
> > those kind of feature bugs as the user can always re-emerge the kernel
> > with their own options.  (its the same exact thing as "why didn't you
> > build such and such GRP package with such and such flag", we just ignore
> > those unless it is a major issue.)
>
> I see you don't realize the enormous headache and impossibility of
> trying to use USE flags to enable or disable different kernel patches.
We aren't planning to do any such thing.  I really wish people would
READ GLEPs before posting.


> But hey, feel free to prove me wrong, I'm eagerly awaiting your
> reference implementation.  Any ETA on it?  :)

Yeah, as soon as I'm done with GentooInstaller.

Nathaniel


--
gentoo-dev@g.o mailing list