Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Sam James]

> On 1 Jan 2022, at 22:21, Piotr Karbowski <slashbeast@g.o> wrote:
>
> Hi,
>
> I'd like to get some insight how others see the concept of narrowing the scope of USE flags in Gentoo.
>
> Taking a quote from devmanual:
>
>  > USE flags are to control optional dependencies and settings which the user may reasonably want to select.
>
> 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.
>
> 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.
>
> 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.
>
> 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.

There's two flags which come to mind:

- USE=ipv6:

IPv6 is a good example of a flag we may want to kill. The reason being that usually the flag
is ineffective -- we don't actually expose it consistently across all packages that may
support it in the build system, and even when there's technically a method for such
In the build system, it's fragile (autoconf cache variables, usually).

A good example of this recently was app-editors/vim. I looked into exactly
what "disabling" IPv6 for an editor meant. _All_ it did was force use of
older POSIX socket functions which lack support for IPv6. These newer
functions which were disabled *were not* IPv6-only.

If you don't want IPv6, you should really disable it in the kernel and
ensure you don't have any IPv6 interfaces setup.

I genuinely don't think USE=ipv6 adds any value most of the time
for the aforementioned reasons. If it really does enable/disable
a huge chunk of code, maybe it makes sense to keep it for such
a package, but in general, every time I've checked, it's
been nebulous.

TL;DR: The flag doesn't exist in plenty of packages
and usually it's rather fragile. I don't think we should keep
it where it toggles something simple like Vim (I removed it
for that reason).

- USE=threads:

Rather dangerous flag at this point, I reckon. We should really
default to on/off as appropriate per-upstream. Usually upstream
roll with one supported configuration (it's either recommended
you have it on or off) and that's it.

If someone puts "USE=threads" in make.conf expecting a speedup
or something good to come out of it, they'd be mistaken.

I'd prefer to only keep it for where there's some API change
or meaningful reason to want it. Otherwise we should just default to
upstream behaviour.


>
> 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.
>
> Beside 'ipv6', there are other USE flags that I have on mind. 'pam' being another of them.

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
first step would actually be forcing PAM on. But I don't think PAM is a candidate for dropping.

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
breaking it for the sake of it is a good idea. They already know there be dragons.

>
> Whats your view on it?

I think I broadly agree, although PAM is a mildly controversial example.

I'd like to discuss specific examples of flags like USE=threads, some-if-not-all instances of USE=ipv6,
And others which people raise if any others come up.

Best,
sam