| 1 |
On Thu, 2003-08-07 at 09:02, Michael Cummings wrote: |
| 2 |
> Perhaps a silly question, but why are patches rolled as their own kernels at |
| 3 |
> all? Seems to my little brain (yes, it's real small when it comes to these |
| 4 |
> matters) that it would almost make more sense to offer the vanilla kernel as |
| 5 |
> is, then have each of these (currently their own ebuilds) patches as add on |
| 6 |
> ebuilds, such as emerge vanillia-kernel, emerge grsecurity-patch, emerge |
| 7 |
> nvidia-patch, etc. After all, it's not like the ebuild for the kernel |
| 8 |
> compiles it in the first place, and as far as I know these patches |
| 9 |
> add/replace to the existing structure, right? Just a random thought, feel |
| 10 |
> free to ignore :) |
| 11 |
|
| 12 |
The only problem with that is that in the case of the gentoo-sources, |
| 13 |
there are hundreds of patches applied, which have to be tested and |
| 14 |
modified to allow them all to work together. It would be nearly |
| 15 |
impossible to ensure that a grsecurity-patch would interact well with |
| 16 |
both a nvidia-patch and crypto-patch. This is the reason for the |
| 17 |
different sources, they are groups of patches that have been tested to |
| 18 |
work together and apply cleanly to each other. It would be possible to |
| 19 |
do things as a vanilla kernel sources and a bunch of patch ebuilds if we |
| 20 |
had about 500 more devs on the kernel team. ;p |
| 21 |
|
| 22 |
-- |
| 23 |
Chris Gianelloni |
| 24 |
Developer, Gentoo Linux |
Archives