| 1 |
On Sun, 2004-05-02 at 19:45 -0700, Greg KH wrote: |
| 2 |
> On Sun, May 02, 2004 at 10:04:35PM -0400, Nathaniel McCallum wrote: |
| 3 |
> > The new glep is here: http://www.gentoo.org/proj/en/glep/glep-0026.html |
| 4 |
> |
| 5 |
> Hm, did you consult the current kernel developers/maintainers/packagers |
| 6 |
> before creating this? At first glance I see a number of issues that |
| 7 |
> would make this completely impractical and impossible to implement. |
| 8 |
Yes. Actually, a lot of people have talked about it. |
| 9 |
|
| 10 |
> Also, have you taken a look at the current genkernel work being done for |
| 11 |
> 2.6? It probably resolves lots of the issues it sounds like you |
| 12 |
> currently have with the kernel packaging process. |
| 13 |
|
| 14 |
Yes. This GLEP is basically a reworking of genkernel into portage. |
| 15 |
Please understand it is bad design to have two build systems. Two build |
| 16 |
systems means one of them has a bug (ie doesn't support needed types of |
| 17 |
building). |
| 18 |
|
| 19 |
> I do find the idea of packaging up a "binary" kernel a bit interesting, |
| 20 |
> but who is going to be doing that packaging? And who is going to |
| 21 |
> mediate the zillion different "but why don't you select this kernel |
| 22 |
> option instead" requests that will be caused by such a package? :) |
| 23 |
|
| 24 |
Users can do their own packageing, then can also supply their own binary |
| 25 |
kernels. This is very much desireable for enterprise users (think |
| 26 |
clusters especially) and for Gentoo Installer. We will not be accepting |
| 27 |
those kind of feature bugs as the user can always re-emerge the kernel |
| 28 |
with their own options. (its the same exact thing as "why didn't you |
| 29 |
build such and such GRP package with such and such flag", we just ignore |
| 30 |
those unless it is a major issue.) |
| 31 |
|
| 32 |
Nathaniel |
| 33 |
|
| 34 |
|
| 35 |
-- |
| 36 |
gentoo-dev@g.o mailing list |
Archives