Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4034 bytes --]


Eli Schwartz <eschwartz93@gmail.com> writes:

> [[PGP Signed Part:Undecided]]
> On 2/9/24 2:57 PM, Michael Orlitzky wrote:
>> One example I know off the top of my head is dev-lang/php where
>> USE=ipv6 isn't entirely about ipv6 connectivity (although it does do
>> that). It also augments some of the user-facing PHP language functions
>> with ipv6 support. Having them enabled is not a big deal, and PHP is a
>> programming language so you may say that it's atypical, but... for a
>> package that gets a new CVE every week and sits on the public web, I'd
>> just rather have it off?
>
>
> Counterpoint: some PHP program out there is probably vulnerable because
> it tried to validate an ipv6 address and could not distinguish between
> "it's okay" and "idk if it's okay, the function you called does not
> exist" (because php is really that terrible of a language).
>

I was going to make this point as well but I didn't want to go down that
route as I figured it'd come across like I'm questioning Michael, as
oppossed to trying to make a point about using an option simply because
it exists.

i.e. Disabling an option isn't always as simple as it sounds (see
below).

But I'm also not personally wanting to debate that PHP should remove it,
just saying that this sort of consideration should be made and it's part
of why a USE flag for everything is not always great.

We *HAVE* had real problems like this before, see also USE=threads
(check out commit bd4d42f83c774c36bf879a5b7ec89d373546743e).

> [...]
>> I really don't want to fall into a trap where I make up reasons why
>> other people might want to do things and everyone says my reasons are
>> stupid. Everyone is going to have different reasons, and we have a lot
>> of users who are our users because they're edge cases.
>> 
>> It's not unfathomably stupid to build a package without ipv6 or unicode
>> support (whatever that means), and there are no small files to worry
>> about, so I don't think they deserve the special negative treatment.
>
>
> Maintainability matters too. So does user experience in the other
> direction: too many USE flags will lead users to confusion if they don't
> understand what all those flags do, and accidentally choose the wrong
> answer.


also whether the flag then gets tinderboxed, reverse dependencies having
to depend on the right flags, debugging user issues which may not be
obvious (especially if they surface in another application/interface)
because of it...

(It's also worth us having the discussion about whether a flag existing
means a tinderbox should try it, e.g. USE=debug which IMO isn't suitable
for this at all (see also its description) and the kernel stuff like for
secureboot.)

>
> That's not necessarily a reason to remove choice, so much as it is a
> reason to... carefully document what that choice actually gets you.
>
> $ equery -N uses sbcl | grep unicode
>  + + unicode          : Add support for Unicode
>
>
> This is... vague. Good to know that it is enabled by default, but...
> what? What does it do? There is no description in metadata.xml, either.
>
> I think it is fair and reasonable for people to ask people's reasons are
> for doing something when it is not actually obvious what the point is.
> And when a USE flag selects or deselects dependencies, it is very easy
> to know, what exactly "the point" is.
>
> Often, USE flags have an obvious point even without selecting or
> deselecting dependencies -- usually because their maintainers took care
> in describing it in metadata.xml.
>

To pick up on this point: yes, if one concludes the USE flag has merit
and the global description is either poor or has some reason to be
considered spurious in the case of the package, you should consider
documenting it to avoid this question.

Adding a suppression like https://github.com/pkgcore/pkgcheck/issues/478
proposes should really be accompanied by such an improvement anyway for
the benefit of users.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]