Michael Orlitzky <m...@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
signature.asc
Description: PGP signature
