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 BF7DA15815E for ; Sat, 10 Feb 2024 00:11:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ECAD3E2A2C; Sat, 10 Feb 2024 00:10:59 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (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 91F0EE29C3 for ; Sat, 10 Feb 2024 00:10:58 +0000 (UTC) References: <6eae895976c68d4c4a4d2036476d4d100c63c797.camel@gentoo.org> <91f35079-037f-45aa-8041-c964e418818b@gmail.com> <177a7913d39c590f43a8261b96ebf155b642d6a8.camel@gentoo.org> <4a608d4e-a605-41a7-9d64-3ef4247f834b@gmail.com> 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:04:59 +0000 Organization: Gentoo In-reply-to: <4a608d4e-a605-41a7-9d64-3ef4247f834b@gmail.com> Message-ID: <87cyt5rxf5.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: 0ec024fd-ad70-4e24-a8ee-cbd8bfa97b33 X-Archives-Hash: fab4a7aba04b3441ca6f23ad200f59fc --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eli Schwartz 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=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? > > > 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=3Dthreads (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. >>=20 >> 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=3Ddebug 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZca/Dl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZDDpwEAgY4DPUzFbPgV8XkpUN+p1q2VVozIZidJkC+g cSqXmvABAPn52BTpgGX28jRQYPAYxhTpwFskPnQqdm4c2r3bTsYP =EyQE -----END PGP SIGNATURE----- --=-=-=--