Gentoo Archives: gentoo-dev

From: Sam James <sam@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
Date: Sun, 02 Jan 2022 07:34:28
In Reply to: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them. by Piotr Karbowski
1 > On 1 Jan 2022, at 22:21, Piotr Karbowski <slashbeast@g.o> wrote:
2 >
3 > Hi,
4 >
5 > I'd like to get some insight how others see the concept of narrowing the scope of USE flags in Gentoo.
6 >
7 > Taking a quote from devmanual:
8 >
9 > > USE flags are to control optional dependencies and settings which the user may reasonably want to select.
10 >
11 > I'd like to focus on the 'reasonably want' here. While it is commonly agreed on that we interface as USE flags only things that make sense to be togglable, it is not always the case. It is not uncommon to see packages that puts every possible option as USE flag which hardly benefit anyone in some cases.
12 >
13 > It creates artificial choice of USE flag that makes as much sense as building and trying to use solar-powered night vision googles. Possible to be engineered, but makes absolute no sense to exist, yet, there will be someone who will go with it and then things will not work in desired way, bugs will be reported, effort will be wasted on investigation and patching things up.
14 >
15 > As example I'd like to use 'ipv6' USE flag, at the moment of writing this email there's 351 ebuilds in tree that expose ipv6 as USE flag, allow it to be disabled.
16 >
17 > The thing is, it's 2022, and it does not make any sense to *not* support IPv6, even if one does not connect to any network with IPv6, there's no harm to just have it there.
19 There's two flags which come to mind:
21 - USE=ipv6:
23 IPv6 is a good example of a flag we may want to kill. The reason being that usually the flag
24 is ineffective -- we don't actually expose it consistently across all packages that may
25 support it in the build system, and even when there's technically a method for such
26 In the build system, it's fragile (autoconf cache variables, usually).
28 A good example of this recently was app-editors/vim. I looked into exactly
29 what "disabling" IPv6 for an editor meant. _All_ it did was force use of
30 older POSIX socket functions which lack support for IPv6. These newer
31 functions which were disabled *were not* IPv6-only.
33 If you don't want IPv6, you should really disable it in the kernel and
34 ensure you don't have any IPv6 interfaces setup.
36 I genuinely don't think USE=ipv6 adds any value most of the time
37 for the aforementioned reasons. If it really does enable/disable
38 a huge chunk of code, maybe it makes sense to keep it for such
39 a package, but in general, every time I've checked, it's
40 been nebulous.
42 TL;DR: The flag doesn't exist in plenty of packages
43 and usually it's rather fragile. I don't think we should keep
44 it where it toggles something simple like Vim (I removed it
45 for that reason).
47 - USE=threads:
49 Rather dangerous flag at this point, I reckon. We should really
50 default to on/off as appropriate per-upstream. Usually upstream
51 roll with one supported configuration (it's either recommended
52 you have it on or off) and that's it.
54 If someone puts "USE=threads" in make.conf expecting a speedup
55 or something good to come out of it, they'd be mistaken.
57 I'd prefer to only keep it for where there's some API change
58 or meaningful reason to want it. Otherwise we should just default to
59 upstream behaviour.
62 >
63 > While I am all for choice, I am for choice on things that do make sense. For instance, Linux kernel can be built with CONFIG_MULTIUSER=n, someone could argue that since Linux kernel, that is user-configured in Gentoo, can be built without support for other than UID 0, then Gentoo should support it. One of the extreme examples of not supporting something that does not make sense to be supported.
64 >
65 > Beside 'ipv6', there are other USE flags that I have on mind. 'pam' being another of them.
67 Note that having USE flags for things, even if forced on/masked (for the opposite case) is useful for building embedded systems. So, if you wanted to go this route, a sensible
68 first step would actually be forcing PAM on. But I don't think PAM is a candidate for dropping.
70 While I think it's hard to run a modern desktop system without it, there are a fair number of people who do still run -pam and I don't think
71 breaking it for the sake of it is a good idea. They already know there be dragons.
73 >
74 > Whats your view on it?
76 I think I broadly agree, although PAM is a mildly controversial example.
78 I'd like to discuss specific examples of flags like USE=threads, some-if-not-all instances of USE=ipv6,
79 And others which people raise if any others come up.
81 Best,
82 sam


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them. Roy Bamford <neddyseagoon@g.o>