From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6195B1391DB for ; Sat, 26 Jul 2014 08:53:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D83F6E0D6A; Sat, 26 Jul 2014 08:53:20 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F209CE0D66 for ; Sat, 26 Jul 2014 08:53:19 +0000 (UTC) Received: from pomiot.lan (77-254-85-187.adsl.inetia.pl [77.254.85.187]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id D0B8333F155; Sat, 26 Jul 2014 08:53:17 +0000 (UTC) Date: Sat, 26 Jul 2014 10:53:21 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Duncan <1i5t5.duncan@cox.net> Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined Message-ID: <20140726105321.7663d6bd@pomiot.lan> In-Reply-To: References: <53D2A6C8.9060900@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; 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-sha512; boundary="Sig_/JNh994xi=iHhaDEg5Y3FrYG"; protocol="application/pgp-signature" X-Archives-Salt: 077e523c-7132-44f1-935b-987941480d79 X-Archives-Hash: 1842ded5004b429bbd33cc76a1afc3f9 --Sig_/JNh994xi=iHhaDEg5Y3FrYG Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-07-26, o godz. 08:05:32 Duncan <1i5t5.duncan@cox.net> napisa=B3(a): > Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted: >=20 > > Hey all.. So, putting aside for now how much of a mess this would be to > > implement in the virtuals' ebuilds themselves, what do people think of > > changing the virtuals so that they contain an entry in IUSE for each > > provider that can satisfy it? > >=20 > > The idea here is that the package satisfying a virtual could be > > optionally explicitly-chosen through package.use (or USE=3D in make.con= f, > > perhaps) instead of having an entry in @world, that way if nothing > > depends on the virtual then it and the provider can be - --depclean'ed > > from the system. The idea is specifically NOT to have rdeps depend on > > these flags, that would undermine the whole purpose of the virtual; it > > would just be for end-users to set if they so chose. > >=20 > > This may also help with getting portage to peg a virtual's provider to a > > specific package instead of constantly trying to switch from one to > > another, ie, how systemd kept getting pulled in, in relation to the > > upower virtual. >=20 > What about handling each such virtual_USE as a USE_EXPAND? VIRTUAL_* as= =20 > reserved-namespace USE_EXPAND would give us full backward compatibility=20 > along with an immediately identifiable namespace and virtually (heh) no=20 > possibility of confusion with other configuration. USE_EXPAND are global by definition. We ought fight with the abuse of USE_EXPAND rather than make another abuse legitimate. Especially that you're going to increase a lot of new variables quickly for no really good reason. --=20 Best regards, Micha=B3 G=F3rny --Sig_/JNh994xi=iHhaDEg5Y3FrYG Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT02yIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZO9e8QANnfYh+e/jIVmWSalWuWP5n+ jL3G5C8+J6dIhqNs7exzZvP8PTizhXkpbxEQfmZo6HP4GUtpl8LyG1J4pxQ/iqSh 9KgAGt3EXzL+K+TxWGhT31m2jyoIoHdgHsZwPoBFvnDYy+5vby7g3onQOO+BRXDo 5NV/1j+YBrFdV2m3GE2uq7upumJTIyZBxbyb4x45MJ81kvpAyla34UB30lqN9Dp4 710iLjLXgV/7heHxz6OvbMW4koZaYlraERwyBvQU2kjo4HiDqBku5KUvadxRkcWY lK7RjJAje/gknOUj3SUlfXQHp8ug3m2EEJveIk2XaMvN4JUH+fZ3dkskYzo2Amm3 v1W6emmakv/eVC7OA1oA2IJf5GpfA3Byj9+YG8Y9vjVC+e/S16jpL9jhmaAJl2GR g5MmjntLzptv+xiQvV8WScV5KNRrcEGVQsMURjQ780aPPC88aa5JECldBg2gTym5 1MKkkA2Gyl4SoZpE4AANZn+3huWmK6VgHrbksN9I3ZRj0gIkrcjp5xo0psoldUgY OyKcBfZbm3EY6znqRHsse5Z63PpsUhaKdvvVK/YHtkAeTCtiDSpq8KyzdFDiBgbg BSld00iM5ZVl0/RrpEFrH44yjLEfQXPzDE5uaZ86xma46U4OMQS+T9YlrSPAaZAb ftiDyR8qA4QAvYawP/AG =va9D -----END PGP SIGNATURE----- --Sig_/JNh994xi=iHhaDEg5Y3FrYG--