Michael Orlitzky <mjo@gentoo.org> writes:

> On Fri, 2024-02-09 at 14:09 -0500, Eli Schwartz wrote:
>> 
>> Asking out of genuine ignorance: what kind of direct behavioral changes
>> occur as a result of setting or unsetting USE=ipv6.
>
> 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?

A few years ago when this last came up, I ended up digging into a bunch
of USE=ipv6 providers and found that USE=-ipv6 either didn't build, took
a less supported (non-default-upstream) codepath which looked bitrotten,
only toggled default configuration (sometimes via the build system). I
also found several cases where it ended up taking a legacy code path
while the USE=ipv6 one used modern networking functions which happened to then
support IPv6.

For a case like the latter one (and the rest I mention, really),
disabilng kernel support is more appropriate.

But read on wrt PHP.

>
> Unicode support is similar in my mind. Adding "unicode support" to a
> package might be easy (at the cost of some extra memory), but dealing
> with the consequences of unicode is harder. Maybe I don't want to worry
> about homoglyphs and bidirectional text when I'm validating a hostname?
> Life is just simpler without it, if you know you don't need it. Things
> also tend to be more space and memory efficient with features compiled
> out; not to mention that the compile times themselves are improved.
> You're still pulling in "extra dependencies," in a sense, even if
> they're in the same tarball.

I think what you really want is
https://github.com/pkgcore/pkgcheck/issues/478 because you've made the
case as its maintainer for the flags to exist. The discussion really
ends there in such a case given you're considered the matter and decided
it has value in PHP.

The issue is therefore just having a suppression for pkgcheck. The
pkgcheck rule was intended as a hint that something might be suspicious,
rather than indicating it must be removed.

thanks,
sam