1 |
On Mon, Aug 31, 2009 at 01:00:41AM +0100, Mike Auty wrote: |
2 |
> > I missed a bit for the config option. |
3 |
> > If there is NO source of the config data, what do we do? |
4 |
> > Error out or more warnings? |
5 |
> Well, if we can't determine whether a config option's set or not, if |
6 |
> it's not critical (ie, it's ~CHECK), then we warn. If there's any hard |
7 |
> checks, then we error out I suppose. |
8 |
+1. |
9 |
|
10 |
> > This is what I use for my home workstation: |
11 |
> > /etc/portage/profile/virtuals:virtual/linux-sources sys-kernel/git-sources |
12 |
> > /etc/portage/profile/virtuals:virtual/alsa sys-kernel/git-sources |
13 |
> > /etc/portage/profile/package.provided:sys-kernel/git-sources-2.6.30 |
14 |
> > Saves having any fake package like that. |
15 |
> Ah cunning, I'll have to try that... |
16 |
We should document it in the kernel web pages. |
17 |
|
18 |
> > Want to lend a hand fixing up the ebuilds then? I'll work on the eclass sources |
19 |
> > check. |
20 |
> Sure, as long as I sure I know how we're fixing them, I'd be glad to |
21 |
> help. 5:) I'd just be fixing the userspace ones to make sure they're |
22 |
> ~CHECK or would I be doing something else as well? Also should I do |
23 |
> that via bugs and a week's grace period, or would you recommend I just |
24 |
> dive right in? |
25 |
If you feel like reviewing ~140 packages and filing bugs for them, I |
26 |
won't stop you. But I'm just going to go and fix the ones that seem |
27 |
simple enough to me, and only file bugs for the complex ones. |
28 |
|
29 |
> > There IS still a point of having the entirely empty kernel package installed: |
30 |
> > - Split userspace/kernel packages where the userspace package has a dependency |
31 |
> > on the module-providing package. |
32 |
> > - other packages that might have a dependency on the module-providing package. |
33 |
> > - /etc/modprobe.d/ files. |
34 |
> > |
35 |
> > USE=-modules will ONLY block files installed to /lib/modules/. |
36 |
> Ok, presumably USE=-modules will also stop the kernel checks, otherwise |
37 |
> the following could occur. Let's say the foobar package builds external |
38 |
> modules and explicitly requires that foobar not be set in the kernel. |
39 |
> With USE=-modules, there's no internal version and there's no external |
40 |
> version, but the kernel package is installed, and the deps are happy, |
41 |
> even though they'll bug out when it's showtime. |
42 |
|
43 |
Err, I'm not following what you claim is the problem here? |
44 |
|
45 |
cat/foo-mod: |
46 |
inherit linux-mod |
47 |
CONFIG_CHECK="!..." |
48 |
MODULE_NAMES="...." |
49 |
|
50 |
cat/foo-usr: |
51 |
RDEPEND="cat/foo" |
52 |
|
53 |
And say foo-mod provides /dev/foo for some crazy hardware. |
54 |
|
55 |
The user sets USE=-modules because they have built cat/foo-mod on their |
56 |
own, into the kernel. foo-mod installs nothing, foo-usr installs fine. |
57 |
foo-usr runs, and /dev/foo already exists, so it gets used fine. |
58 |
|
59 |
> Presumably there's also packages that aren't split, or depended on, |
60 |
> where not installing the modules is never a good idea. Is there still a |
61 |
> way to disable the USE flag, or will it be a requirement of the |
62 |
> linux-mod package? |
63 |
It needs to be ALWAYS available. The ipset bug I linked earlier in the |
64 |
thread was an example of that. The userspace is useless without the |
65 |
kernel code, but there is nothing to stop the user patching it into |
66 |
their kernel and not having it as a module at all (as is the case on a |
67 |
couple of my work boxes, which is why the bug got filed). |
68 |
|
69 |
-- |
70 |
Robin Hugh Johnson |
71 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
72 |
E-Mail : robbat2@g.o |
73 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |