| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 26/07/14 10:40 AM, Manuel Rüger wrote: |
| 5 |
> On 07/25/2014 08:49 PM, Ian Stakenvicius wrote: |
| 6 |
>> Hey all.. So, putting aside for now how much of a mess this |
| 7 |
>> would be to implement in the virtuals' ebuilds themselves, what |
| 8 |
>> do people think of changing the virtuals so that they contain an |
| 9 |
>> entry in IUSE for each provider that can satisfy it? |
| 10 |
>> |
| 11 |
>> The idea here is that the package satisfying a virtual could be |
| 12 |
>> optionally explicitly-chosen through package.use (or USE= in |
| 13 |
>> make.conf, perhaps) instead of having an entry in @world, that |
| 14 |
>> way if nothing depends on the virtual then it and the provider |
| 15 |
>> can be --depclean'ed from the system. The idea is specifically |
| 16 |
>> NOT to have rdeps depend on these flags, that would undermine the |
| 17 |
>> whole purpose of the virtual; it would just be for end-users to |
| 18 |
>> set if they so chose. |
| 19 |
>> |
| 20 |
>> This may also help with getting portage to peg a virtual's |
| 21 |
>> provider to a specific package instead of constantly trying to |
| 22 |
>> switch from one to another, ie, how systemd kept getting pulled |
| 23 |
>> in, in relation to the upower virtual. Note - I haven't done any |
| 24 |
>> tests to determine if this actually helps with such issues tho |
| 25 |
>> (or even attempted to reproduce them, as i was apparently one of |
| 26 |
>> the lucky ones that it didn't happen to). |
| 27 |
>> |
| 28 |
>> I don't know if this would aid heavy binpkg users or not. |
| 29 |
>> |
| 30 |
>> |
| 31 |
>> For completion, here's one of those rather messy examples: |
| 32 |
>> |
| 33 |
>> --- virtual/krb5-0.ebuild 2013-06-28 09:04:47.000000000 |
| 34 |
>> -0400 +++ virtual/krb5-0.ebuild.new 2014-07-25 |
| 35 |
>> 14:47:48.000000000 -0400 @@ -2,7 +2,7 @@ # Distributed under the |
| 36 |
>> terms of the GNU General Public License v2 # $Header: |
| 37 |
>> /var/cvsroot/gentoo-x86/virtual/krb5/krb5-0.ebuild,v 1.2 |
| 38 |
>> 2013/06/27 20:42:55 aballier Exp $ |
| 39 |
>> |
| 40 |
>> -EAPI=3 +EAPI=5 |
| 41 |
>> |
| 42 |
>> DESCRIPTION="Virtual for Kerberos V implementation" HOMEPAGE="" |
| 43 |
>> @@ -11,7 +11,12 @@ LICENSE="" SLOT="0" KEYWORDS="alpha amd64 arm |
| 44 |
>> hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd |
| 45 |
>> ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos" -IUSE="" |
| 46 |
>> +IUSE="heimdal mit-krb5" |
| 47 |
>> |
| 48 |
>> DEPEND="" -RDEPEND="|| ( app-crypt/mit-krb5 app-crypt/heimdal )" |
| 49 |
>> +RDEPEND="!mit-krb5? ( !heimdal? ( || ( app-crypt/mit-krb5 |
| 50 |
>> app-crypt/heimdal ) ) ) + mit-krb5? ( app-crypt/mit-krb5 ) |
| 51 |
>> + heimdal? ( app-crypt/heimdal )" + +REQUIRED_USE="heimdal? |
| 52 |
>> ( !mit-krb5 ) + mit-krb5? ( !heimdal )" |
| 53 |
>> |
| 54 |
>> |
| 55 |
>> Thoughts? |
| 56 |
>> |
| 57 |
> |
| 58 |
> Thinking in another direction: Would it be possible to introduce |
| 59 |
> "pseudo-versioned" useflags? |
| 60 |
> |
| 61 |
> This would solve a problem for virtual/libusb just with adding |
| 62 |
> IUSE=">=dev-libs/libusb-1.0.18" |
| 63 |
> |
| 64 |
> virtual/libusb-1-r1 depends on either dev-libs/libusb or |
| 65 |
> sys-freebsd/freebsd-lib. The latter one is only compatible with |
| 66 |
> libusb-1.0.9, so packages depending on >dev-libs/libusb-1.0.9 can't |
| 67 |
> use the virtual. |
| 68 |
> |
| 69 |
> Assuming freebsd-lib becomes compatible with dev-libs/libusb |
| 70 |
> again, packages will have to switch back to the virtual to support |
| 71 |
> both. |
| 72 |
> |
| 73 |
> Depending on virtual/libusb[>=dev-libs/libusb-1.0.18(+)] instead |
| 74 |
> would just need a change in the virtual. |
| 75 |
> |
| 76 |
> Cheers, |
| 77 |
> |
| 78 |
> Manuel |
| 79 |
> |
| 80 |
|
| 81 |
This sounds like something that should still be doable with two |
| 82 |
versions of the virtual/libusb package... I mean, if something |
| 83 |
*needs* a newer libusb than 1.0.9 , then it should appropriately |
| 84 |
depend on a virtual/libusb that needs it. Otherwise, it shouldn't |
| 85 |
matter which provider provides virtual/libusb-1 , right?? So we keep |
| 86 |
virtual/libusb-1 as-is, and add a virtual/libusb-1.0.10 (or whatever |
| 87 |
version is appropriate) for anything that needs a newer one. That |
| 88 |
newer one would need to have a !sys-freebsd/freebsd-lib in it, I |
| 89 |
think, to help keep it from being allowed to upgrade, but that itself |
| 90 |
might not be necessary. |
| 91 |
|
| 92 |
Or is it more complicated than that and i'm missing something? |
| 93 |
-----BEGIN PGP SIGNATURE----- |
| 94 |
Version: GnuPG v2 |
| 95 |
|
| 96 |
iF4EAREIAAYFAlPWXDwACgkQ2ugaI38ACPBrOAD9EXzlINqnSFQ/SvSTcvVyiMLr |
| 97 |
ZkMzt4ud98dvItB++5oBAKIg5Nc0p4jjtAj/DN1YsBw8yWkRyCLylJ6G7iKeeKT3 |
| 98 |
=U9cS |
| 99 |
-----END PGP SIGNATURE----- |
Archives