1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Robin H. Johnson wrote: |
5 |
> It does NOT check /proc/config.gz presently. The original logic against |
6 |
> not checking /proc was that we were targeting the kernel being built, |
7 |
> but that's moot given the use of `uname -r` in OUTPUT_DIR. |
8 |
|
9 |
I might be reading the eclass wrong, but it looks as though OUTPUT_DIR |
10 |
is only set to use uname -r if the KV_* variables match the output of |
11 |
uname -r: |
12 |
|
13 |
[ "${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}" == "$(uname -r)" ] && \ |
14 |
OUTPUT_DIR="${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}" |
15 |
|
16 |
Otherwise it's taken from the KBUILD_DIR and then it even checks inside |
17 |
the KV_DIR's Makefile to find one. So not checking /proc/config.gz |
18 |
isn't a moot point anymore, which is not to say it's not a good idea, |
19 |
but the reason against doing it still stands. To deal with running |
20 |
kernel's, there's a get_running_version function, that will use uname to |
21 |
fill out the KV_* variables appropriately. |
22 |
|
23 |
> Proposed solution: |
24 |
> ------------------ |
25 |
> We need to be able to reduce user error, so we cannot simply make it |
26 |
> trust the user by default. So I propose that we add an environment |
27 |
> variable (I'm not set on the name yet), eg: |
28 |
> EXTERNALLY_BUILT_KERNEL=1 |
29 |
> |
30 |
> This option will cause linux-info.eclass to consider ALL kernel option |
31 |
> checks non-fatal. That way we still get the warnings and logs, but it |
32 |
> does not stop the builds. |
33 |
|
34 |
I'm not sure what this is solving? It doesn't seem to reduce user |
35 |
error, it just allows users a way to override portage errors? It seems |
36 |
unrelated to config.gz and the discussion going on in the previous |
37 |
thread. I do like the idea of being able to override portage when it's |
38 |
stopping us from building (incorrectly), but surely with the capability |
39 |
to have non-fatal checks, we can try to minimize the times when |
40 |
portage/the ebuild is wrong using that, instead of a whole new override? |
41 |
|
42 |
> When is the above NOT enough? |
43 |
> ----------------------------- |
44 |
> The only time that ANY kernel sources are required is when you are |
45 |
> building an out-of-tree module. For this purpose, they must be |
46 |
> configured. |
47 |
|
48 |
There's a lot of ebuilds that use linux-info, and they can't all be |
49 |
out-of-tree modules. Are they misusing linux-info, or are you saying |
50 |
there's a specific instance in which linux-info requires configured |
51 |
kernel sources? |
52 |
|
53 |
> The check for having configured kernel sources must only be executed |
54 |
> when the modules are about to be compiled. Putting it in pkg_preinst |
55 |
> would block use of binpkgs on (related) machines. |
56 |
> |
57 |
> - If a package builds modules AND userspace, we should offer a way to |
58 |
> build the userspace only, as the user can build their modules |
59 |
> externally (or patch them into the kernel) [1] |
60 |
> - For packages that ONLY build modules, and no userspace at all, having |
61 |
> EXTERNALLY_BUILT_KERNEL=1 means that they should error out? [2] |
62 |
> (this case might be thrown into the above one). |
63 |
|
64 |
That all seems fine, but again these just seem like standard guidelines. |
65 |
Is there not already some "how to write kernel module ebuilds" page |
66 |
somewhere that documents how you're supposed to use linux-info? |
67 |
|
68 |
Mike 5:) |
69 |
-----BEGIN PGP SIGNATURE----- |
70 |
Version: GnuPG v2.0.11 (GNU/Linux) |
71 |
|
72 |
iEYEARECAAYFAkqa30QACgkQu7rWomwgFXo99gCfd8NbK9QkxtJ9BKalq/n1iBxn |
73 |
l0QAoLiBsvKXZRzR4Dp8HEtoxrsONCtc |
74 |
=ZK9i |
75 |
-----END PGP SIGNATURE----- |