| 1 |
On Sun, May 02, 2004 at 11:39:22PM -0400, Nathaniel McCallum wrote: |
| 2 |
> On Sun, 2004-05-02 at 20:32 -0700, Greg KH wrote: |
| 3 |
> > > > Also, please realize that the 2.6 kernel build process is infinitely |
| 4 |
> > > > better than the 2.4 one, and based on it, a number of your listed |
| 5 |
> > > > objections and proposals are pretty moot. |
| 6 |
> > > |
| 7 |
> > > Like binary packaging support? |
| 8 |
> > |
| 9 |
> > Yes. |
| 10 |
> |
| 11 |
> How does the 2.6 kernel build process allow one to create a binary |
| 12 |
> package that is fully integrated with portage. |
| 13 |
|
| 14 |
You never mentioned portage in your question :) |
| 15 |
The 2.6 kernel build process provides the ability to generate a binary |
| 16 |
.deb or .rpm package today. Why not look into modifying it to also |
| 17 |
support creating a binary portage file? All of the necessary hooks are |
| 18 |
provided for you already... |
| 19 |
|
| 20 |
> Integration with portage is essential (for security updates, etc). We |
| 21 |
> all know how secure the kernel has been this last year. Just think |
| 22 |
> emerge --security would now support kernels in a fully automated |
| 23 |
> fashion. |
| 24 |
|
| 25 |
I agree this would be good to have. A number of us are working on |
| 26 |
fixing up the current security process to more closely match that of the |
| 27 |
other distros (0 day security updates, instead of always playing |
| 28 |
catch-up). |
| 29 |
|
| 30 |
> > > Being able to keep around just the kernel headers? |
| 31 |
> > |
| 32 |
> > You can keep a read-only kernel tree. Sorry, but that's necessary, you |
| 33 |
> > can't throw away all of the source and expect to build an external |
| 34 |
> > module properly. Or so states the current kernel build authors. |
| 35 |
> |
| 36 |
> All you need is the headers. |
| 37 |
|
| 38 |
This is not true at all. Have you tried it? I just did, and it failed |
| 39 |
misserably. You need to keep major portions of the kernel source tree |
| 40 |
around in order to build external kernel modules. And if you need to |
| 41 |
keep large chunks, why not just keep everything? That saves a |
| 42 |
redownload in order to apply a security fix, or even to do another build |
| 43 |
with a different configuration. Remember, disk space is cheap :) |
| 44 |
|
| 45 |
> You can do away with about 50% or more of the tree. Plus, because we |
| 46 |
> are implementing at the eclass level, we can keep the tree compressed |
| 47 |
> as a tarball, saving more space. |
| 48 |
|
| 49 |
And are you proposing that we uncompress the tarball every time a |
| 50 |
package needs to build against the kernel source tree? If so, that |
| 51 |
seems like a lot of work for very little gain. |
| 52 |
|
| 53 |
> > > A single API for all package building? |
| 54 |
> > |
| 55 |
> > The kernel build process has nothing to do with building a package, |
| 56 |
> > although it does currently provide the ability to build a .deb and .rpm. |
| 57 |
> |
| 58 |
> Which is helpful to gentoo how? This is a portage integration issue. |
| 59 |
|
| 60 |
See my above comments for why this _could_ be helpful to Gentoo if you |
| 61 |
so desired it to be. |
| 62 |
|
| 63 |
thanks, |
| 64 |
|
| 65 |
greg k-h |
| 66 |
|
| 67 |
-- |
| 68 |
gentoo-dev@g.o mailing list |
Archives