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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id EB03B139085 for ; Sat, 4 Feb 2017 00:35:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 66A25E0D19; Sat, 4 Feb 2017 00:35:23 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0A52BE0CC8 for ; Sat, 4 Feb 2017 00:35:22 +0000 (UTC) Received: from katipo2.lan (unknown [IPv6:2406:e001:1:d01:de0e:a1ff:fea1:6ec4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id A3609340E75 for ; Sat, 4 Feb 2017 00:35:21 +0000 (UTC) Date: Sat, 4 Feb 2017 13:34:55 +1300 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Guidelines for IUSE defaults Message-ID: <20170204133455.24604bad@katipo2.lan> In-Reply-To: References: <3a32da5b-e7f8-c21d-a990-ffbedb2c958b@gentoo.org> <0b9e6324-9d41-e35f-d077-1496e0bac05d@gentoo.org> <68433328-e9a2-03ec-bad7-c81a0d8f442c@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/rLlYXM56tR3rW4A4cZf3pSx"; protocol="application/pgp-signature" X-Archives-Salt: a6c7b117-fb45-4b72-b3b3-2902a6af4dbe X-Archives-Hash: 0623e978820068fd4af6c458deffd07f --Sig_/rLlYXM56tR3rW4A4cZf3pSx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 2 Feb 2017 18:01:54 -0600 Gordon Pettey wrote: > If you want to keep this kind of thing in the ebuilds, IUSE=3D"+blah" doe= sn't > allow any granularity. Another variable USE_PROFILE should be added > analogue to DEPENDS: > IUSE=3D"gnome-keyring gtk-theme kwallet pulseuadio qt-theme > annoyingUpstreamDefault" > USE_PROFILE=3D" > desktop? ( pulseaudio ) > gtk? ( gtk-theme ) > gnome? ( @gtk gnome-keyring) > kde? ( @qt kwallet ) > qt? ( qt-theme ) > upstream? ( annoyingUpstreamDefault ) > " This is the way I'd suggest going as well. Mostly, because needless double-= accounting by communicating this same information to a global profile seems like creat= ing work without benefit. I'd probably suggest something like this, but with a restriction that every "foo?" on the left hand side being a defined global term. Especially considering that USE=3D"-*" doesn't necessarily give you "less d= ependencies", in the case of dev-util/pkgconfig, USE=3D"-*" aligns with the existing (def= ault) mechanic of USE=3D"-internal-glib", and so a "minimal system" would either=20 a. Prefer dev-util/pkgconf which doesn't require glib at all ( bug #606260 = [1] ) b. Prefer USE=3D"internal-glib" Clearly given bug #606260, our current mechanism of following upstream defa= ults is not ideal for minimal systems, even though its fine for 99.99% of users. Hence, I'd prefer something akin to: virtual/pkgconfig:=20 RDEPEND=3D" profile:minimal? (=20 || ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] dev-util/pkgconfig= ) ) +profile:upstream? ( || ( dev-util/pkgconfig dev-util/pkgconf ) ) " Granted here I'm stepping slightly outside the conversation of USE defaults= , because this is a related system where the concepts of defaults are present, but ar= e instead regulated by implicit controls based on what the user has already decided t= o install. And this example suggested usage is a bit dodgy because it could be abused = by people using profiles instead of useflags to control behaviour. However: IUSE=3D"minimal" IUSE_PROFILES=3D" minimal? ( minimal ) " RDEPEND=3D" minimal? (=20 || ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] dev-util/pkgconfig= ) ) !minimal? ( || ( dev-util/pkgconfig dev-util/pkgconf ) ) " Would be less abusey. Also, this approach in general means instead of needing repoman to compute = the interaction of x for all(@profiles), it only needs to compute t= he interactions for Profile X x Profile Y for union(x.profiles y.profiles) ( Though personally I don't think repoman needs to compute anything for def= aults, I just saw somebody else mention this in a different part of this thread = and it confused me. However, it *could* be useful to be able to ensure cohesion within a = single chosen profile name, being able to state "If you set your profile to X and don't= change anything in package.use, everything that has profile X will be installable as-is" ) And this of course brings into observation my favourite negative-useflag, for which USE=3D"-*" will have the opposite effect to that you intend. __ SIMPLIFIED __=20 # May contain only the possible useflags, not setting defaults=20 IUSE=3D"" # A list of "profilename ? ( assumed defaulted on flags )" # where "profilename" must be a defined profile ID # "profilename" can have a "+" to indicate it is the default profile # if none of the others listed in IUSE_PROFILES matches a user description IUSE_PROFILES=3D""=20 > @ is already used for sets, so "some other use_profile's set of defined > flags" seems reasonable. It should be additive only, so no +- prefixes > needed (or allowed). If a package is emerged without any USE_PROFILE set, > you might einfo "This package supports was emerged with no use profile. It > supports blah1, blah2, and blah3. Upstream recommends blah2." USE_PROFILE > should never have any default selected by an ebuild; if a flag is required > to build, is shouldn't be a flag. You get independent behavior per package > rather than listing every single package that ever existed in > profile/package.use, package behavior actually being with the package > instead of global profiles, and you get rid of the mess of uncustomizable > IUSE=3D"+something" everywhere that makes people like me tend to start off > every new Gentoo install with echo "USE=3D\"-*\"" >> /etc/portage/make.co= nf. > Just need to come up with sane naming convention for common possibilities > like kde, gnome, and generic desktop. Personally, I think encouraging people to set profiles on a per-package lev= el fights the cause of this feature in ways that should be governed by USE fla= gs. The real utility of profile-governed defaults is that you should select a g= iven profile, and *everything* should work out of the box *without* needing to c= hange use flags, and repoman should compute how "my profiles defaults expanded in= to dependencies" would introduce a need to change USE flags on dependencies, and should raise warnings when this happens. If A and B both have 2 profiles each, and depend on a third package C, which has only 0 or 1 profiles (ie: "the only profile is a default profile"= ), then as long as both A and B's profiles don't require changes in C, this sh= ould be "legal" C could enhance things later by adding an additional profile more in line w= ith A and B, changing the defaults to get closer to the ideals that profile def= ines. And if A and B have profiles that necessitate C changing use flags, that sh= ould cause repoman to error until a suitable profile is added to C that matches A and B. Though yes, I understand I'm kinda thinking of a different way to implement mixin profiles without necessitating a lot of global state to regulate it, = so mgorny probably hates me. >=20 > If you want upstream, USE_PROFILE=3D"upstream". If Gentoo as an organizat= ion > wants that to be the "friendly to new user" standard, put > USE_PROFILE=3D"upstream" in the stage3 make.conf, where those of us who w= ant > to can simply remove or change it instead of having to nuke everything wi= th > USE=3D"-*". You can still use e.g. RUBY_TARGETS=3D"+ruby21" in an ebuild = if you > want a default for things that really require an at-least-one-of choice. >=20 > Then instead of default/linux/amd64/13.0/desktop/kde listing any USE flags > itself, it just sets required USE_PROFILE and lets the packages do their > thing. The only thing left that leaves me in a state of "ugh, this could be ugly" is how application of multiple profile-use should be handled, if we go that= way. Naturally some packages A and B will have different profiles, and so you'll want to pick 2 ...=20 I guess this is where 'additive only' is helpful to an extent, but this opens complexity city where additive unioning of multiple profiles in a single package end up introducing a REQUIRED_USE mutual-exclusion, thwarting the incentive for profiles entirely. Unless ...=20 IUSE_PROFILES=3D" desktop & upstream & !gtk & !gnome -> ( qt ) desktop & upstream & ( gtk | gnome ) -> ( gtk qt ) desktop & !upstream & ( gtk | gnome ) -> ( gtk ) "=20 Ugh. No. This is all horrible. My head hurts just thinking about it. Freedom of Choice is freedom to suffer in new and innovative ways. 1: https://bugs.gentoo.org/606260 --Sig_/rLlYXM56tR3rW4A4cZf3pSx Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPZazbI/qrFT1o9rn6FQySxNmqCAFAliVIbwACgkQ6FQySxNm qCB+sA/+NI66sVJP3tTtFFCeXIFVLRlVgYcQpYgIEnJJ42uaKKOHHbQK5pvIrZdw jdlLhQPjjN1FCNYBmYydGQxJYfXysE0TCpQYXWtdJuXK+JXGiAX+W4qp0WnqJ1Va 70Ms+z1km3ASKBEKrkacmCQZkEtb2DT+0bmQaQEmUdTjJfylCI7MpB23oF9O95sd H20LX1zh9ETh8DTILErGkmcQRqMur79tUdFQaCvfsGyyHXszyljLeOVvV9+NbTyH InwlpHJjw+TcsBxgiLr4YrVMLLhzWG92MYgYXvxgIiDofylxqZJ51SdxXNX52GU6 FbTVBqsEKusIv49vO4cKC5MLL2h5dW41d7YPd/bc5lZm97Xzk0LDrLiZ5bVbd0dO yUsv+jAVfN83gd9iWoTFjlICHRLXQjGdt0DlseBLBhCkCPpKOTUwqrFWD+bu8oF5 jIsSnPiLpMZ67165P+5MkRmV9A+fcimAR9bZurfs2cxizUo3IYZv6+Z2fjanbJMu 6g4m3kF/u0Xi7uwHEt3GNectpQeyhZYJe7It4M67OOONhwuaWH3iApbOi9zkUQJ6 33tr86TN37tvAZ73XrkYK/C1wu7Yxx0M+chxgSAAIIYyAZ5gVGJBjQDKZuhQkFCA JIJO7t5euEGSxSeob4bBWw04dpmdnccxfpCIMdKFsMmZlIz7qb0= =7X5z -----END PGP SIGNATURE----- --Sig_/rLlYXM56tR3rW4A4cZf3pSx--