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

[Greg KH]

On Sun, May 02, 2004 at 11:18:02PM -0400, Nathaniel McCallum wrote:
> 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.

Ok, will do so in a new response after this one.

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

Yes.

> Being able to keep around just the kernel headers?

You can keep a read-only kernel tree.  Sorry, but that's necessary, you
can't throw away all of the source and expect to build an external
module properly.  Or so states the current kernel build authors.

> A single API for all package building?

The kernel build process has nothing to do with building a package,
although it does currently provide the ability to build a .deb and .rpm.

> Actually, none of the reasons for the GLEP are solved by the 2.6
> kernel build process (although it is bettter).

I still think a few of them are.  But I can agree to disagree :)

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

You do not address the currently "in-development" process in the GLEP
from what I can see.

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

Ok, so after the new process builds up a binary kernel, how will it
install it on another machine?

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

I did.  However in re-reading it I realize I mistook the
"USE=bootsplash" option the wrong way.  I am sorry about that
misunderstanding.

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

Ok, I guess we don't really have to worry about this anytime soon
then... :)

greg k-h

--
gentoo-dev@g.o mailing list