From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 27EA515815E for ; Sat, 10 Feb 2024 00:03:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 07E22E2ADE; Sat, 10 Feb 2024 00:03:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B7F6FE2ADC for ; Sat, 10 Feb 2024 00:03:51 +0000 (UTC) References: <6eae895976c68d4c4a4d2036476d4d100c63c797.camel@gentoo.org> <91f35079-037f-45aa-8041-c964e418818b@gmail.com> <177a7913d39c590f43a8261b96ebf155b642d6a8.camel@gentoo.org> User-agent: mu4e 1.10.8; emacs 30.0.50 From: Sam James To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ] Date: Sat, 10 Feb 2024 00:00:14 +0000 Organization: Gentoo In-reply-to: <177a7913d39c590f43a8261b96ebf155b642d6a8.camel@gentoo.org> Message-ID: <87jzndrxr0.fsf@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Archives-Salt: 9a46f55c-5621-4b22-a2df-2e00076294ff X-Archives-Hash: 57a4d0a30edc75fe6ce437d43386d04f --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Orlitzky writes: > On Fri, 2024-02-09 at 14:09 -0500, Eli Schwartz wrote: >>=20 >> Asking out of genuine ignorance: what kind of direct behavioral changes >> occur as a result of setting or unsetting USE=3Dipv6. > > One example I know off the top of my head is dev-lang/php where > USE=3Dipv6 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=3Dipv6 providers and found that USE=3D-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=3Dipv6 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZca9Y18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZDVzQD8DTR8fZQ/CYYDTo0bB4NVYMywXI4p9m2f1wyJ wsu6ZI8BAP6nWjznwGTkUBFbkU+OymsV9iseaFCdl9KO6f3yAmMJ =UO4O -----END PGP SIGNATURE----- --=-=-=--