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 ABADA1391DB for ; Tue, 29 Jul 2014 04:51:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0929DE0E41; Tue, 29 Jul 2014 04:51:24 +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 0C5D7E0CBC for ; Tue, 29 Jul 2014 04:51:22 +0000 (UTC) Received: from pomiot.lan (87-205-65-151.adsl.inetia.pl [87.205.65.151]) (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 E4B3D340141; Tue, 29 Jul 2014 04:51:20 +0000 (UTC) Date: Tue, 29 Jul 2014 06:51:26 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Ian Stakenvicius Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined Message-ID: <20140729065126.00886605@pomiot.lan> In-Reply-To: <53D6822F.6090507@gentoo.org> References: <53D2A6C8.9060900@gentoo.org> <20140728132118.0c421aeb@pomiot.lan> <53D6822F.6090507@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_/84wzZwjNxTPQmS_8xNDok7O"; protocol="application/pgp-signature" X-Archives-Salt: 173ccc0d-fcb2-4965-9401-05c0e58394eb X-Archives-Hash: 4ef4febf5f6c34fd4345d635f925f820 --Sig_/84wzZwjNxTPQmS_8xNDok7O Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-07-28, o godz. 13:02:39 Ian Stakenvicius napisa=B3(a): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 28/07/14 07:21 AM, Micha=B3 G=F3rny wrote: > > Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius > > napisa=B3(a): > >=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=20 > >> optionally explicitly-chosen through package.use (or USE=3D in=20 > >> make.conf, 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 > > I think I don't get this argument. > >=20 > > If you really want to have a particular provider for the virtual > > for external purposes, it's fully purposeful to put it in @world > > or otherwise in a custom set. In this case, USE flags aren't > > helpful. >=20 > The argument I was trying to make is that USE flags would allow > end-users to accomplish the same thing, while not having an entry in > @world and therefore allowing the package to be --depclean'ed if the > virtual is --depcleaned. If you need it externally, you need it not depcleaned, obviously. So you have to have something in @world. If you need a specific implementation, it's more elegant to put that in @world rather than the virtual and playing with USE flags. > > If you only prefer a particular provider, you can tip portage > > easily to use it without resorting to USE flags. This also allows > > portage to semi-transparently switch to other provider if > > dependencies need it. In this case, USE flags only make this > > auto-switching harder. >=20 > That is the other part of this idea, to make auto-switching harder, > because right now portage likes to auto-switch even when it seems like > it shouldn't. This is a bug in portage and should be fixed there. As I said, working it around will only fix it for one package, and it will happen again and again, possibly in cases harder to pinpoint. --=20 Best regards, Micha=B3 G=F3rny --Sig_/84wzZwjNxTPQmS_8xNDok7O Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT1yhRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOa2UP/jPKjJ6+Mfy/PYGZUPBW5uEz KN/dZlX48c65bW7FjKCyci84EoYATvinE2lXSdDyT3eREkn9hNGAYOEudAlL166a XvMkG1vF1Z6ZhvgDzI41zDsWbXoUzaBlQE/j/Uyuu61yDRk+Mwa8hNPKlvFPRBx/ 6miZrnAMir7pXe3QUFudPS0CTl8vpLJ/TI/a+z6IGdN6Y0ooon1GV0ixvcEAztp4 pp5eE9sV8+F/16e8QtsVZOxw0bizT8B5iQncI2iNDXv3NB9NeRh0+w9jzwKKgfz/ /Onu5qEF+BYbBQHloJU8UD95uo7NDkTHaDhnb9hvgh38+fACqPYXgzruciocM7df 9UP/30PC+OkeQybkv9Xc9gkZONSSgmDAmm7HTNk5+e7fcKiz6MV+GAQ67NF0MKKc BF/4+8nOMdr1v91JziinGy1N2HuvRgp/+ZtiMnY8CiXFDHtE3xg4NeJgnaveghGE iqIFFEY0iX0X52np6WFcy45+x1vu00bsazzFM9OfiQdFK+tRIvkIWyNx5z4CWSIR Bj/DuE+YoVL+3DajVfcgPRe3+jCGrq8U6qYpM5WcXf7voAkF0dKwtd9CC2DUi7wf IT+v9dCavGPDjArTYoNnKosCmNUgzOgQ/pH9acuMT52AeH3bfj7LM5sQHXUikjxH y7grRq5xd9j9UpDIz5Bm =AElT -----END PGP SIGNATURE----- --Sig_/84wzZwjNxTPQmS_8xNDok7O--