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