| 1 |
On Sun, May 02, 2004 at 10:54:26PM -0400, Nathaniel McCallum wrote: |
| 2 |
> On Sun, 2004-05-02 at 19:45 -0700, Greg KH wrote: |
| 3 |
> > On Sun, May 02, 2004 at 10:04:35PM -0400, Nathaniel McCallum wrote: |
| 4 |
> > > The new glep is here: http://www.gentoo.org/proj/en/glep/glep-0026.html |
| 5 |
> > |
| 6 |
> > Hm, did you consult the current kernel developers/maintainers/packagers |
| 7 |
> > before creating this? At first glance I see a number of issues that |
| 8 |
> > would make this completely impractical and impossible to implement. |
| 9 |
> Yes. Actually, a lot of people have talked about it. |
| 10 |
|
| 11 |
Ok, did johnm sign off on this? As he is the current Gentoo kernel |
| 12 |
maintainer I would expect you would have run this by him. |
| 13 |
|
| 14 |
Do you want me to outline my objections to this proposal here, or is |
| 15 |
there some other place to do it? |
| 16 |
|
| 17 |
> > Also, have you taken a look at the current genkernel work being done for |
| 18 |
> > 2.6? It probably resolves lots of the issues it sounds like you |
| 19 |
> > currently have with the kernel packaging process. |
| 20 |
> |
| 21 |
> Yes. This GLEP is basically a reworking of genkernel into portage. |
| 22 |
|
| 23 |
Yes you have seen the new work? And no, you don't like it? Or yes, you |
| 24 |
like it and think it can help out? Confused here... :) |
| 25 |
|
| 26 |
> Please understand it is bad design to have two build systems. |
| 27 |
|
| 28 |
Ivory towers are over that-a-way. Real world is here :) Come on, the |
| 29 |
build system for the kernel is just so much more complex than what the |
| 30 |
current portage system can even begin to support, based on what you are |
| 31 |
trying to propose. |
| 32 |
|
| 33 |
Also, please realize that the 2.6 kernel build process is infinitely |
| 34 |
better than the 2.4 one, and based on it, a number of your listed |
| 35 |
objections and proposals are pretty moot. |
| 36 |
|
| 37 |
> Two build systems means one of them has a bug (ie doesn't support |
| 38 |
> needed types of building). |
| 39 |
|
| 40 |
Could you perhaps outline your current objections and problems with the |
| 41 |
current build system, contrast it with the currently being worked on |
| 42 |
changes to that build system, and maybe we can work from there? |
| 43 |
|
| 44 |
> > I do find the idea of packaging up a "binary" kernel a bit interesting, |
| 45 |
> > but who is going to be doing that packaging? And who is going to |
| 46 |
> > mediate the zillion different "but why don't you select this kernel |
| 47 |
> > option instead" requests that will be caused by such a package? :) |
| 48 |
> |
| 49 |
> Users can do their own packageing, then can also supply their own binary |
| 50 |
> kernels. |
| 51 |
|
| 52 |
Do we allow this with the current -bin packages already? I might be |
| 53 |
mistaken, but I didn't think we did for some reason... |
| 54 |
|
| 55 |
> This is very much desireable for enterprise users (think clusters |
| 56 |
> especially) and for Gentoo Installer. We will not be accepting |
| 57 |
> those kind of feature bugs as the user can always re-emerge the kernel |
| 58 |
> with their own options. (its the same exact thing as "why didn't you |
| 59 |
> build such and such GRP package with such and such flag", we just ignore |
| 60 |
> those unless it is a major issue.) |
| 61 |
|
| 62 |
I see you don't realize the enormous headache and impossibility of |
| 63 |
trying to use USE flags to enable or disable different kernel patches. |
| 64 |
Trust me, as someone who used to get paid to package a kernel up for a |
| 65 |
distro for a number of years, and as someone who builds more kernels |
| 66 |
every day than most people do all year long, it will not work. |
| 67 |
|
| 68 |
But hey, feel free to prove me wrong, I'm eagerly awaiting your |
| 69 |
reference implementation. Any ETA on it? :) |
| 70 |
|
| 71 |
thanks, |
| 72 |
|
| 73 |
greg k-h |
| 74 |
|
| 75 |
-- |
| 76 |
gentoo-dev@g.o mailing list |
Archives