Gentoo Archives: gentoo-dev

From: Martin Schlemmer <azarah@g.o>
To: Gentoo-Dev <gentoo-dev@g.o>
Subject: Re: [gentoo-dev] KUSE....
Date: Wed, 26 Dec 2001 17:16:42
Message-Id: 1009408117.5912.2.camel@nosferatu.lan
In Reply to: [gentoo-dev] KUSE.... by Zach Forrest
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

Replies

Subject Author
Re: [gentoo-dev] KUSE.... Zach Forrest <diatribe@××××.ca>
Re: [gentoo-dev] KUSE.... Terje Kvernes <terjekv@××××××××.no>