| 1 |
Mike Gilbert wrote: |
| 2 |
> > > It's a waste of time and effort to pepper random ebuilds with checks |
| 3 |
> > > for options that everyone should have enabled in the first place. |
| 4 |
> > |
| 5 |
> > It's not for you to say what everyone should have enabled in their kernel. |
| 6 |
> |
| 7 |
> Do you not agree that there are some options that should always be |
| 8 |
> enabled, or at least that we can assume are enabled? |
| 9 |
|
| 10 |
"Should be enabled" no, but I agree with the latter - some assumed set |
| 11 |
should be fine. I think it would be good if it's (somehow) documented |
| 12 |
though. |
| 13 |
|
| 14 |
|
| 15 |
> To use my earlier example, should every package that uses AF_INET |
| 16 |
> check for CONFIG_INET in the kernel? |
| 17 |
|
| 18 |
CONFIG_INET is a perhaps surprisingly tricky example! |
| 19 |
|
| 20 |
A package could e.g. use getaddrinfo() with no address family hint |
| 21 |
but because of USE=-ipv6 exclude all AF_INET6 address results and |
| 22 |
so end up using AF_INET based on whether it's available in the |
| 23 |
running kernel or even based on third party DNS entries. |
| 24 |
|
| 25 |
|
| 26 |
I'm not sure about the best approach for very basic options, |
| 27 |
CONFIG_NET could be another such candidate. |
| 28 |
|
| 29 |
Thinking towards robbat2's proposal (which I like) it might make sense |
| 30 |
to try to map requirements of packages, but there will probably be |
| 31 |
cases where it can't really be done successfully. |
| 32 |
|
| 33 |
Ultimately that work should not be the responsibility of distribution |
| 34 |
package maintainers but something upstreams deliver, similar to systemd |
| 35 |
units, but maybe we'll invent it (if noone else has).. |
| 36 |
|
| 37 |
|
| 38 |
//Peter |
Archives