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

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

[Nathaniel McCallum]

The new glep is here: http://www.gentoo.org/proj/en/glep/glep-0026.html

Nathaniel


--
gentoo-dev@gentoo.org mailing list

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

[Greg KH]

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.

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.

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

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

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

[Nathaniel McCallum]

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.

> 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.
Please understand it is bad design to have two build systems.  Two build
systems means one of them has a bug (ie doesn't support needed types of
building).

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

Nathaniel


--
gentoo-dev@gentoo.org mailing list

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

[Greg KH]

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.

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

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

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

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.

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

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

> 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.
Trust me, as someone who used to get paid to package a kernel up for a
distro for a number of years, and as someone who builds more kernels
every day than most people do all year long, it will not work.  

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

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

[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@gentoo.org mailing list

[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@gentoo.org mailing list

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

[Nathaniel McCallum]

On Sun, 2004-05-02 at 20:32 -0700, Greg KH wrote:
> > > 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.

How does the 2.6 kernel build process allow one to create a binary
package that is fully integrated with portage.  Integration with portage
is essential (for security updates, etc).  We all know how secure the
kernel has been this last year.  Just think emerge --security would now
support kernels in a fully automated fashion.

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

All you need is the headers.  You can do away with about 50% or more of
the tree.  Plus, because we are implementing at the eclass level, we can
keep the tree compressed as a tarball, saving more space.

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

Which is helpful to gentoo how?  This is a portage integration issue.


> You do not address the currently "in-development" process in the GLEP
> from what I can see.
Plasmaroo has not outlined anything to me, but he had to leave tonight, so maybe
he ran out of time.


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

It is the same as creating any other portage binary package.  We can also make GRP
binary kernel packages.

Nathaniel


--
gentoo-dev@gentoo.org mailing list

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

[Greg KH]

On Sun, May 02, 2004 at 11:39:22PM -0400, Nathaniel McCallum wrote:
> On Sun, 2004-05-02 at 20:32 -0700, Greg KH wrote:
> > > > 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.
> 
> How does the 2.6 kernel build process allow one to create a binary
> package that is fully integrated with portage.

You never mentioned portage in your question :)
The 2.6 kernel build process provides the ability to generate a binary
.deb or .rpm package today.  Why not look into modifying it to also
support creating a binary portage file?  All of the necessary hooks are
provided for you already...

> Integration with portage is essential (for security updates, etc).  We
> all know how secure the kernel has been this last year.  Just think
> emerge --security would now support kernels in a fully automated
> fashion.

I agree this would be good to have.  A number of us are working on
fixing up the current security process to more closely match that of the
other distros (0 day security updates, instead of always playing
catch-up).

> > > 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.
> 
> All you need is the headers.

This is not true at all.  Have you tried it?  I just did, and it failed
misserably.  You need to keep major portions of the kernel source tree
around in order to build external kernel modules.  And if you need to
keep large chunks, why not just keep everything?  That saves a
redownload in order to apply a security fix, or even to do another build
with a different configuration.  Remember, disk space is cheap :)

> You can do away with about 50% or more of the tree.  Plus, because we
> are implementing at the eclass level, we can keep the tree compressed
> as a tarball, saving more space.

And are you proposing that we uncompress the tarball every time a
package needs to build against the kernel source tree?  If so, that
seems like a lot of work for very little gain.

> > > 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.
> 
> Which is helpful to gentoo how?  This is a portage integration issue.

See my above comments for why this _could_ be helpful to Gentoo if you
so desired it to be.

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

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

[Nathaniel McCallum]

Some good news and some bad news.  I just found out I got a new job (and
I am starting training today).  Therefore, I'll be a little slow when
responding to the GLEP related stuff.  So, just be patient with me,
thanks! :)

Nathaniel


--
gentoo-dev@gentoo.org mailing list

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

[Duncan]

Nathaniel McCallum posted
<1083554281.28957.22.camel@aquinas.natemccallum.com>, excerpted below,  on
Sun, 02 May 2004 23:18:02 -0400:

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

I'm just a Gentoo newbie, here, but this is my opinion, FWIW..

The fact that the kernel remains an exception to the normal build
process is a GOOD thing, IMO.  It accentuates its uniqueness and extreme
customizability (think the impossible to support with use flags thing),
and the fact that without it, you are dead-in-the-water.

I do NOT think that having all traces of a kernel, both the binary (and
modules) and its source tree removed with emerge unmerge would be a good
thing. Having to remove the pieces manually again accentuates the
differences and the fact that this is NOT just another ebuild on the
system.

I might as well have the same opinion about glibc as well, were it not so
standardized, due to the fact that a modern system is about as helpless
without it as it is without a bootable kernel.  However, it happens to be
close enough to monolithic (unlike the kernel with its modules), with few
enough fast-changing hardware dependencies (unlike the kernel) and a slow
enough significant upgrade cycle (unlike the kernel), that it's convenient
to do a source2binary ebuild for, and the advantages of doing it that way
outweigh the disadvantages (unlike the kernel, IMO).

People choose Gentoo because they like the customizability.  With
genkernel providing a solution for those that don't want to get /that/
into customizing, while still accentuating the fact that the kernel
/really/ /is/ different, I simply see no reason (other than the security
thing, definitely a valid point, but addressable on its own separately) to
integrate full kernel handling into portage, and overarching reasons NOT
to do so, including BOTH the difficulty of doing so, AND the benefits of
NOT doing so.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

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

[John Nilsson]

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

On Thu, 2004-05-06 at 13:31, Duncan wrote:
> The fact that the kernel remains an exception to the normal build
> process is a GOOD thing, IMO.  It accentuates its uniqueness and extreme
> customizability (think the impossible to support with use flags thing),
> and the fact that without it, you are dead-in-the-water.

I might add that to incorporate the kernel fully into the portage system
one would have to make ebuilds for each module. That is just more work
than it's worth.

-John

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Nathaniel McCallum]

On Sun, 2004-05-02 at 19:45 -0700, Greg KH wrote:
> At first glance I see a number of issues that
> would make this completely impractical and impossible to implement.

And what are those?  You failed to mention.

Nathaniel


--
gentoo-dev@gentoo.org mailing list

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

[Greg KH]

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?

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

>	2. Check to see if customized kernel config/settings have been
>	   set via Stage 1.
>	3. Portage will use a custom config, if available.  Otherwise, a
>	   "generic" config.
>	4. If neither a custom config or a "generic" config is
>	   available, die (with message).  This is needed as some arches
>	   don't/can't have "generic" configs, so they will simply be
>	   presented a message telling them to run the utility from
>	   Stage 1 (which they obviously skipped).
>	5. Build the kernel and modules and install them
>	6. Remove unnecessary files from the sources and tarball it as
>	   "kernel-headers". This tarball provides the appropriate files
>	   to build external modules against, like nvidia-kernel, etc...
>	   The external modules (when built) will determine the running
>	   kernel and unpack the appropriate tarball, to build against,
>	   then remove the files.

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

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

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

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

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

>	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 yes, there are a few packages that want to use kernel header files
in their build process, but that's another issue to deal with and take
care of...

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

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


So in summary, again, I understand the objections to the current
situation.  However I do not see how the proposal really helps solve the
issue.  If a reference implementation was created it would be easier to
discuss it at that time.

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

[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@gentoo.org mailing list

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

[John Nilsson]

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

> "yes | make oldconfig".

This seems like a stupid thing to do.
CONFIG_UNSTABLE_PANIC_ON_BOOT=y
CONFIG_FILESYSTEM_DESTRUCTION=y


How would this system update the bootmgr?

-John



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Nathaniel McCallum]

On Mon, 2004-05-03 at 07:40 +0200, John Nilsson wrote:
> > "yes | make oldconfig".
> 
> This seems like a stupid thing to do.
> CONFIG_UNSTABLE_PANIC_ON_BOOT=y
> CONFIG_FILESYSTEM_DESTRUCTION=y

I think it actually does "yes 'n' | make oldconfig".

> How would this system update the bootmgr?
I purposely left this out of the GLEP as it is would be a much more hot
topic.  At this point, bootmgrs would not be updated.  However, we will
be writing a script to scan for kernel/initrd's and adding them to the
boogmgr for the GentooInstaller project.

Nathaniel



--
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

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

On Monday 03 May 2004 07:04, Nathaniel McCallum wrote:
> I purposely left this out of the GLEP as it is would be a much more hot
> topic.  At this point, bootmgrs would not be updated.  However, we will
> be writing a script to scan for kernel/initrd's and adding them to the
> boogmgr for the GentooInstaller project.
>
> Nathaniel

Wouldn't it make sense to produce a working and viable GentooInstaller first?

I'm sorry, but nothing helps credibility like shipping working code ...

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

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

[Todd Berman]

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

On Mon, 2004-03-05 at 11:12 +0100, Stuart Herbert wrote:
> On Monday 03 May 2004 07:04, Nathaniel McCallum wrote:
> > I purposely left this out of the GLEP as it is would be a much more hot
> > topic.  At this point, bootmgrs would not be updated.  However, we will
> > be writing a script to scan for kernel/initrd's and adding them to the
> > boogmgr for the GentooInstaller project.
> >
> > Nathaniel
> 
> Wouldn't it make sense to produce a working and viable GentooInstaller first?
> 
> I'm sorry, but nothing helps credibility like shipping working code ...
> 

I might be daft, or stupid, or mistaking identity (all have been known
to happen often ;) ). But i believe if you look at:

http://glis.sf.net (url might be bad, google for glis or something)

you can find an existing working and viable gentoo installer made by
Nathaniel.

> 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: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Stuart Herbert]

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

On Monday 03 May 2004 11:18, Todd Berman wrote:
> I might be daft, or stupid, or mistaking identity (all have been known
> to happen often ;) ). But i believe if you look at:
>
> http://glis.sf.net (url might be bad, google for glis or something)
>
> you can find an existing working and viable gentoo installer made by
> Nathaniel.

Unless I'm missing something, the last release from that project was over six 
months ago (v0.1 final).  The last commit into CVS was over two months ago. 
The last update to the website was over six months ago.  And Nathanial's last 
contribution to the mailing lists was December 2003.

And wasn't the Gentoo Installer supposed to be a replacement for GLIS anyhow?

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

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

[Patrick Börjesson]

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

> > I might be daft, or stupid, or mistaking identity (all have been known
> > to happen often ;) ). But i believe if you look at:
> >
> > http://glis.sf.net (url might be bad, google for glis or something)
> >
> > you can find an existing working and viable gentoo installer made by
> > Nathaniel.
> 
> Unless I'm missing something, the last release from that project was over six 
> months ago (v0.1 final).  The last commit into CVS was over two months ago. 
> The last update to the website was over six months ago.  And Nathanial's last 
> contribution to the mailing lists was December 2003.
> 
> And wasn't the Gentoo Installer supposed to be a replacement for GLIS anyhow?

I might be mistaken, but didn't Nathaniel join in on developing the GLI
instead of GLIS?

Patrick Börjesson

-- 
Public key ID: 4C5AB0BF
Public key available at wwwkeys.pgp.net

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

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

[Andrew Gaffney]

Patrick Börjesson wrote:
>>>I might be daft, or stupid, or mistaking identity (all have been known
>>>to happen often ;) ). But i believe if you look at:
>>>
>>>http://glis.sf.net (url might be bad, google for glis or something)
>>>
>>>you can find an existing working and viable gentoo installer made by
>>>Nathaniel.
>>
>>Unless I'm missing something, the last release from that project was over six 
>>months ago (v0.1 final).  The last commit into CVS was over two months ago. 
>>The last update to the website was over six months ago.  And Nathanial's last 
>>contribution to the mailing lists was December 2003.
>>
>>And wasn't the Gentoo Installer supposed to be a replacement for GLIS anyhow?
> 
> 
> I might be mistaken, but didn't Nathaniel join in on developing the GLI
> instead of GLIS?

Yep, and he abandoned all of us over at GLIS... *sniff* :)

-- 
Andrew Gaffney
Network Administrator
Skyline Aeronautics, LLC.
636-357-1548


--
gentoo-dev@gentoo.org mailing list

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

[Nathaniel McCallum]

On Mon, 2004-05-03 at 12:18 +0100, Stuart Herbert wrote:
> On Monday 03 May 2004 11:18, Todd Berman wrote:
> > I might be daft, or stupid, or mistaking identity (all have been known
> > to happen often ;) ). But i believe if you look at:
> >
> > http://glis.sf.net (url might be bad, google for glis or something)
> >
> > you can find an existing working and viable gentoo installer made by
> > Nathaniel.
> 
> Unless I'm missing something, the last release from that project was over six 
> months ago (v0.1 final).  The last commit into CVS was over two months ago. 
> The last update to the website was over six months ago.  And Nathanial's last 
> contribution to the mailing lists was December 2003.
> 
> And wasn't the Gentoo Installer supposed to be a replacement for GLIS anyhow?

If you would have read that "last contribution to the mailing list" you
would have found out that I was leaving to get married, go on my
honeymoon, move halfway across the country, start school, settle in with
my wife, become a gentoo developer, and start working on the new
GentooInstaller project (a better replacement for GLIS).  It seems like
I may have done all those things...  You might want to ask when my last
commit to the official Gentoo CVS was, rather than on an old project.

Nathaniel


--
gentoo-dev@gentoo.org mailing list

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

[Nathaniel McCallum]

On Mon, 2004-05-03 at 11:12 +0100, Stuart Herbert wrote:
> On Monday 03 May 2004 07:04, Nathaniel McCallum wrote:
> > I purposely left this out of the GLEP as it is would be a much more hot
> > topic.  At this point, bootmgrs would not be updated.  However, we will
> > be writing a script to scan for kernel/initrd's and adding them to the
> > boogmgr for the GentooInstaller project.
> >
> > Nathaniel
> 
> Wouldn't it make sense to produce a working and viable GentooInstaller first?
> 
> I'm sorry, but nothing helps credibility like shipping working code ...

Just wait and see.  But in the mean time, don't be so cynical.

Nathaniel


--
gentoo-dev@gentoo.org mailing list

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

[Greg KH]

On Mon, May 03, 2004 at 02:04:11AM -0400, Nathaniel McCallum wrote:
> On Mon, 2004-05-03 at 07:40 +0200, John Nilsson wrote:
> > > "yes | make oldconfig".
> > 
> > This seems like a stupid thing to do.
> > CONFIG_UNSTABLE_PANIC_ON_BOOT=y
> > CONFIG_FILESYSTEM_DESTRUCTION=y
> 
> I think it actually does "yes 'n' | make oldconfig".

Even doing that is also stupid, and will not work (think about all of
the config options that are a number, or a selection from a list of
items, such as the CPU type.)

Or what if the kernel developers introduce a new config option:
	CONFIG_FIX_ALL_BUGS
You wouldn't want to always turn that off now would you?  :)

> > How would this system update the bootmgr?
> I purposely left this out of the GLEP as it is would be a much more hot
> topic.

???

That's the easiest thing to do, and something that I'm pretty amazed
Gentoo has not implemented yet, as all other distros already come with a
simple script that handles this functionality (works with different boot
loaders too...)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

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

[John Mylchreest]

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

On Mon, 2004-05-03 at 17:22, Greg KH wrote:
> > > How would this system update the bootmgr?
> > I purposely left this out of the GLEP as it is would be a much more hot
> > topic.
> 
> ???
> 
> That's the easiest thing to do, and something that I'm pretty amazed
> Gentoo has not implemented yet, as all other distros already come with a
> simple script that handles this functionality (works with different boot
> loaders too...)

I havent yet read on from this email in the thread, but fyi - I have a
working system to do this with grub/lilo. it is "modular" so would work
with any other. It can just be tagged into this system or any other.
I shall dig it out and email it it/commit it/do somethign with it

-- 
Regards
John Mylchreest

Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 0xEAB9E721		 
Key fingerprint: 0670 E5E4 F461 806B 860A  2245 A40E 72EB EAB9 E721
Web:             http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEAB9E721

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

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

On Wed, 05 May 2004 17:33:36 +0100 John Mylchreest <johnm@gentoo.org>
wrote:
| On Mon, 2004-05-03 at 17:22, Greg KH wrote:
| > > > How would this system update the bootmgr?
| > > I purposely left this out of the GLEP as it is would be a much
| > > more hot topic.
| > 
| > ???
| > 
| > That's the easiest thing to do, and something that I'm pretty amazed
| > Gentoo has not implemented yet, as all other distros already come
| > with a simple script that handles this functionality (works with
| > different boot loaders too...)
| 
| I havent yet read on from this email in the thread, but fyi - I have a
| working system to do this with grub/lilo. it is "modular" so would
| work with any other. It can just be tagged into this system or any
| other. I shall dig it out and email it it/commit it/do somethign with
| it

silo should be easy enough to add, it's fairly similar to lilo. The only
problem is there's no way to tell where the user has put their
silo.conf...

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

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

[Greg KH]

Ick, please fix your email client to properly format your long lines
(i.e. no line wrapping.)  I've reformatted them below to be sane...

You also took the thread off of gentoo-dev, that's not nice either...

On Sun, May 02, 2004 at 10:20:39PM -0600, Joshua Campbell wrote:
> On Sun, 2 May 2004 20:56:47 -0700
> Greg KH <gregkh@gentoo.org> 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?
> > 
> 
> Yes, we will probably hook into the alread existing configure system.

That is not what you were stating.  Please document this if it is going
to be so.

> The extra tool isn't much more than a wrapper for it, however it is
> needed so that portage can manage the kernel configs [supply the
> config when the kernel is built, when modules are built, when a newer
> kernel is configured, when the kernel is rebuilt, when the initrd is
> built].

initrd has nothing to do with the kernel config.  Also see my previous
comments about initrd going the way of the dinosaurs...

> > > 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?
> 
> With genkernel, yes, we are just simply using this ability of
> genkernel's in a more modular fasion.

Again, your proposal never said anything about using the current
genkernel functions or functionality.  Again, please revise it if this
is going to be so.

> You do not need the whole tree around to build modules.  For example,
> an x86 system would never need the sparc-specific parts of the kernel
> to build module.

Down this path lies madness...  Trust me, see the zillion different
threads about this very topic on the linux-kernel mailing list.  Also
note that the majority of files in the kernel source tree are not in the
arch specific portion, but rather in the drivers/ section.

You need a good portion of the tree to build modules.  This is easily
proved with a simple test.  Also see my previous comments about the
infeasibility of handing this when trying to build other packages that
want kernel source present somewhere...

> Yet again, we aren't scrapping genkernel, we're enhancing it.

Again, this is the first time this has been mentioned.

In fact, to quote the GLEP:
	This GLEP hopes to overcome this by abstracting the various
	layers of genkernel and implementing the most common aspect (the
	build procedure) into a portage eclass.

That sure doesn't sound like "enhancing" genkernel.  Sounds more like
grabbing the genkernel code and reforming it into something else at the
very best reading.

> > > 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?
> > 
> 
> This is an example.  USE flags would not be used to configure the
> kernel, but rather dependancies as shown above.

So are you stating that "bootspash" and "initrd" are going to be the
only dependencies?  You do realize that the "bootsplash" option requires
a kernel patch to be applied?  If I don't specify the "bootsplash"
option, I sure don't want that patch applied to my kernel (perhaps
because I live in a place that decrees that this specific patch is
illegal...) 

"bootsplash" also affects the kernel config options.  As does "initrd",
correct?  So how can you state that these flags will not be used to
configure the kernel when your example clearly shows them doing so?

Also, what happens if a security fix is needed that is around the same
portions of the kernel code that the bootsplash code is at?  That would
require 2 different security patches to be in the repository, and 2
different tests to determine if the patch works properly or not.

Multiply this by a zillion different "requests" that I know we will get,
and it will quickly get unwieldy.

For example, we currently have a "usb" use flag.  Should the kernel
build process honor it?  If so, does that mean we need to split the
existing lirc patch up into 2 pieces (one for the usb driver, and one
for the rest)?

That's what I am talking about when I mention the total ickyness that
will ensue if we try to use USE flags to modify the kernel build
process.

> > 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.
> 
> Modularing the initrd system will only help us prepare for this eventuality.

Huh?  It isn't already in the genkernel tool?  What is the function
"create_initrd" used for?  :)

> > > 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.
> 
> It is easier to port things in parts ["configs" and initrd] than it is
> as a whole.

But this proposal says nothing about porting "things in parts".  It
talks about a replacement for our current kernel build system.

> > >	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.
> 
> If initrd goes away we will NEED that flexibility.

What flexibility?  initramfs works on every platform and provides _more_
flexibility.  I don't understand your objection here.

> It will be easier to create a reference implementation if developers
> such as yourself will have open mind.

I have a very open mind.  I'm trying to show the problems I see in this
proposal (which is why you all posted it, correct?)  That's part of the
review process.  Hopefully in the end something better than a person
working by themselves will be created.  That's the main strength of open
source development.

So that's about it for my objections.  I eagerly await your reference
implementation, and your revised GLEP proposal based on this
implementation.  As the GLEP process states:

	The GLEP should be reviewed and accepted before a reference
	implementation is begun, unless a reference implementation will
	aid people in studying the GLEP. Standards Track GLEPs must
	include an implementation -- in the form of code, patch, or URL
	to same -- before it can be considered Final.

For this GLEP, I propose that a reference implementation is necessary
before we can properly study this GLEP and see if it is acceptable or
not.

Any objections?

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sun, 02 May 2004 22:04:35 -0400 Nathaniel McCallum
<npmccallum@gentoo.org> wrote:
| The new glep is here:
| http://www.gentoo.org/proj/en/glep/glep-0026.html

> (as a dependency) download and install a tarball of "generic" kernel
> config files.

Where are these going to come from?

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

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

[Nathaniel McCallum]

On Mon, 2004-05-03 at 09:57 +0100, Ciaran McCreesh wrote:
> On Sun, 02 May 2004 22:04:35 -0400 Nathaniel McCallum
> <npmccallum@gentoo.org> wrote:
> | The new glep is here:
> | http://www.gentoo.org/proj/en/glep/glep-0026.html
> 
> > (as a dependency) download and install a tarball of "generic" kernel
> > config files.
> 
> Where are these going to come from?

Split off from the current genkernel package.  Like I mentioned in the
GLEP, as per our conversation on this topic, not all arches may be
eligible for generic config files.

Nathaniel


--
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

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

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.

If genkernel is broken - why not redo^H^H^Hfix genkernel instead?

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.

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.

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

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.

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.

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

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

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

I think this GLEP needs significant revision before it's worth serious 
consideration.  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.

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

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@gentoo.org mailing list

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

[Stuart Herbert]

[-- 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 --]

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

[John Nilsson]

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

Would anyone be interested in improving the GLEP process?
Some thoughts:

A GLEP should have three parts

1. A case for the problem.
	This document will discuss the problem.
	* Is there a problem?
	* What is the nature of the problem?
	* Who is affected by the problem?
	* Should the problem be solved?

2. Solution requirement analysis.
	This document will declare the requirements that a proposed 	solution
will be tested against.

3. Solution
	A document describing the solution.

Each document should be accepted before the next part is worked on. A
document MUST have a version history. A solution(3) MUST link to a
particular version of the SRA(2) which MUST link to a particular version
of problem(1).

I also suggest a wiki-like development model for documents.

-John

On Mon, 2004-05-03 at 18:36, Stuart Herbert wrote:
> On Monday 03 May 2004 16:15, Nathaniel McCallum wrote:
> > 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[N. Owen Gunden]

On Tue, May 04, 2004 at 12:48:37AM +0200, John Nilsson wrote:
> Would anyone be interested in improving the GLEP process?
> Some thoughts:
> [...]

Maybe you should make a GLEP for this :).

--
gentoo-dev@gentoo.org mailing list

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

[John Nilsson]

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

If people think it is worth pursuing I will... eventually =)

-John

On Wed, 2004-05-05 at 03:16, N. Owen Gunden wrote:
> On Tue, May 04, 2004 at 12:48:37AM +0200, John Nilsson wrote:
> > Would anyone be interested in improving the GLEP process?
> > Some thoughts:
> > [...]
> 
> Maybe you should make a GLEP for this :).
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]