1 |
On 27/09/21 18:10, Mike Gilbert wrote: |
2 |
> I'm looking to solicit opinions on when it is appropriate for an |
3 |
> ebuild to check for kernel config options using linux-info.eclass. I |
4 |
> don't think we have any guidelines documented, instead leaving it up |
5 |
> to the "common sense" of package maintainers. |
6 |
> |
7 |
> Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns |
8 |
> when running emerge, so we should do so only when there is a |
9 |
> compensating benefit. It doesn't make sense to check for kernel |
10 |
> options that are very commonly enabled. But what is "very common"? |
11 |
> |
12 |
> An obvious example would be CONFIG_INET, which controls IPv4 support |
13 |
> in the kernel. It does not make sense to check for that in every |
14 |
> package that uses AF_INET sockets. |
15 |
> |
16 |
> A less obvious example: a user filed a bug against net-misc/dhcpcd |
17 |
> today asking that we check for CONFIG_PACKET [1]. My first thought was |
18 |
> "why would you ever disable that?". The option description even says |
19 |
> "if unsure, say Y". However, I suppose it is technically possible to |
20 |
> run a Linux system with it disabled. |
21 |
> |
22 |
> I think a reasonable rule of thumb would be to assume we can rely on |
23 |
> options that are enabled by "make defconfig". If the user chooses to |
24 |
> disable them, they are responsible for anything that breaks. |
25 |
> |
26 |
> Thoughts? |
27 |
|
28 |
We can document in the wiki that going against defconfig means you keep |
29 |
the pieces when something explodes colorfully and/or come up with a even |
30 |
smaller list of config items expected. |
31 |
|
32 |
|
33 |
lu |