1 |
On Wed, 2001-12-26 at 23:36, Zach Forrest wrote: |
2 |
> I'm just working on adding a couple of optional patches to the latest |
3 |
> linux-sources ebuild, one of which is a patch to use the BeOS file |
4 |
> system. Now, I know this is going to see very little interest, but I |
5 |
> like to have it. Is there a reason that, instead of using USE flags in |
6 |
> the linux-sources ebuild, one has to uncomment a patch version to enable |
7 |
> a feature like mosix? This seems less elegant that USE flags. |
8 |
> |
9 |
> One thing that I'd like to see is a KUSE variable for kernel specific |
10 |
> customizations. So, my KUSE variable might look like: |
11 |
> |
12 |
> KUSE="xfs acpi lowlatency preemptive grsecurity befs" |
13 |
> |
14 |
> I think there are some valid arguments for keeping kernel specific flags |
15 |
> isolated from the rest of the system (though it isn't a requirement, of |
16 |
> course). Using a KUSE varaible (or just USE) would make the |
17 |
> linux-sources ebuild both more consistent with the rest of the system |
18 |
> and make customization much more elegant (rather that having to |
19 |
> uncomment a line in each new ebuild, I need only specify the options I |
20 |
> desire once in make.conf). |
21 |
> |
22 |
> In Debian, make-kpkg was a nice tool, but having the kernel sources |
23 |
> downloaded and patched the way you want in one step is without equal. |
24 |
> |
25 |
> Nne flaw with this proposal would be any overlap in the USE and KUSE |
26 |
> variables. For example, gradm is needed to work with the ACL system in |
27 |
> grsecurity, so do I need to specify "grsecurity" in one or both of the |
28 |
> variables? One way avoid having to duplicates is for "userspace" ebulds |
29 |
> to chech both USE and KUSE and have the linux-sources only check KUSE |
30 |
> (which, of course, could be transparent -- `use x` checks both USE and |
31 |
> KUSE, where `kuse x` only checks KUSE). I personally like the idea of |
32 |
> isolating the parameters for the kernel, but there is also an argument |
33 |
> for only having USE. |
34 |
> |
35 |
> Thoughts? |
36 |
> |
37 |
|
38 |
Not so easy. You see, Daniel put in lots of time doing the |
39 |
ebuilds for linux-sources, etc, because most of the time |
40 |
things do not patch nicely. And some patches breaks others, |
41 |
so you need to patch in the right order, and fix them to |
42 |
then patch corretly. Thurther more some patches depends on |
43 |
others, so you see, for this to work, you will need to |
44 |
make the ebuild to complicated to support every possible |
45 |
option in the 'KUSE' flag you want implemented. |
46 |
|
47 |
Just a side note, did you ever try and patch the kernel |
48 |
with the AC patches and grsecurity? Hidious ;-) |
49 |
|
50 |
Then to come back to the grsecurity patch. It 'infests' too |
51 |
many parts of the kernel, for most patches to patch clean, |
52 |
thus even the more reason you cant switch stuff on and off |
53 |
like you would like to see. |
54 |
|
55 |
As it is now, all the patches you can enable/disable during |
56 |
'make menuconfig', so in having them all already applied, |
57 |
should be no hassle in my opinion. |
58 |
|
59 |
I also do not think we should include grsecurity. It is like |
60 |
I already stated, a invasive patch, touching from FS to |
61 |
NET/NETFILTER code. And, it being what it is, most people |
62 |
will not run it except on a very high risc server that |
63 |
absolutely need that extra security. For a desktop box for |
64 |
instance, it just cause too many hassles (sound problems, |
65 |
games like UT, etc just getting killed at start, etc). |
66 |
|
67 |
This in *my* opinion falls into the 'do it yourself' catagory. |
68 |
|
69 |
|
70 |
Greetings, |
71 |
|
72 |
-- |
73 |
|
74 |
Martin Schlemmer |
75 |
Gentoo Linux Developer, Desktop Team Developer |
76 |
Cape Town, South Africa |