1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 28/07/14 10:42 AM, Micha³ Górny wrote: |
5 |
> Dnia 2014-07-28, o godz. 10:20:44 Ian Stakenvicius |
6 |
> <axs@g.o> napisa³(a): |
7 |
> |
8 |
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 |
9 |
>> |
10 |
>> On 26/07/14 10:40 AM, Manuel Rüger wrote: |
11 |
>>> On 07/25/2014 08:49 PM, Ian Stakenvicius wrote: |
12 |
>>>> Hey all.. So, putting aside for now how much of a mess this |
13 |
>>>> would be to implement in the virtuals' ebuilds themselves, |
14 |
>>>> what do people think of changing the virtuals so that they |
15 |
>>>> contain an entry in IUSE for each provider that can satisfy |
16 |
>>>> it? |
17 |
>>>> |
18 |
>>>> The idea here is that the package satisfying a virtual could |
19 |
>>>> be optionally explicitly-chosen through package.use (or USE= |
20 |
>>>> in make.conf, perhaps) instead of having an entry in @world, |
21 |
>>>> that way if nothing depends on the virtual then it and the |
22 |
>>>> provider can be --depclean'ed from the system. The idea is |
23 |
>>>> specifically NOT to have rdeps depend on these flags, that |
24 |
>>>> would undermine the whole purpose of the virtual; it would |
25 |
>>>> just be for end-users to set if they so chose. |
26 |
>>>> |
27 |
>>>> This may also help with getting portage to peg a virtual's |
28 |
>>>> provider to a specific package instead of constantly trying |
29 |
>>>> to switch from one to another, ie, how systemd kept getting |
30 |
>>>> pulled in, in relation to the upower virtual. Note - I |
31 |
>>>> haven't done any tests to determine if this actually helps |
32 |
>>>> with such issues tho (or even attempted to reproduce them, |
33 |
>>>> as i was apparently one of the lucky ones that it didn't |
34 |
>>>> happen to). |
35 |
>>>> |
36 |
>>>> I don't know if this would aid heavy binpkg users or not. |
37 |
>>>> |
38 |
>>>> |
39 |
>>>> For completion, here's one of those rather messy examples: |
40 |
>>>> |
41 |
>>>> --- virtual/krb5-0.ebuild 2013-06-28 09:04:47.000000000 |
42 |
>>>> -0400 +++ virtual/krb5-0.ebuild.new 2014-07-25 |
43 |
>>>> 14:47:48.000000000 -0400 @@ -2,7 +2,7 @@ # Distributed under |
44 |
>>>> the terms of the GNU General Public License v2 # $Header: |
45 |
>>>> /var/cvsroot/gentoo-x86/virtual/krb5/krb5-0.ebuild,v 1.2 |
46 |
>>>> 2013/06/27 20:42:55 aballier Exp $ |
47 |
>>>> |
48 |
>>>> -EAPI=3 +EAPI=5 |
49 |
>>>> |
50 |
>>>> DESCRIPTION="Virtual for Kerberos V implementation" |
51 |
>>>> HOMEPAGE="" @@ -11,7 +11,12 @@ LICENSE="" SLOT="0" |
52 |
>>>> KEYWORDS="alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 |
53 |
>>>> s390 sh sparc x86 ~amd64-fbsd ~amd64-linux ~x86-linux |
54 |
>>>> ~ppc-macos ~x86-macos" -IUSE="" +IUSE="heimdal mit-krb5" |
55 |
>>>> |
56 |
>>>> DEPEND="" -RDEPEND="|| ( app-crypt/mit-krb5 |
57 |
>>>> app-crypt/heimdal )" +RDEPEND="!mit-krb5? ( !heimdal? ( || ( |
58 |
>>>> app-crypt/mit-krb5 app-crypt/heimdal ) ) ) + mit-krb5? |
59 |
>>>> ( app-crypt/mit-krb5 ) + heimdal? ( app-crypt/heimdal |
60 |
>>>> )" + +REQUIRED_USE="heimdal? ( !mit-krb5 ) + mit-krb5? |
61 |
>>>> ( !heimdal )" |
62 |
>>>> |
63 |
>>>> |
64 |
>>>> Thoughts? |
65 |
>>>> |
66 |
>>> |
67 |
>>> Thinking in another direction: Would it be possible to |
68 |
>>> introduce "pseudo-versioned" useflags? |
69 |
>>> |
70 |
>>> This would solve a problem for virtual/libusb just with adding |
71 |
>>> IUSE=">=dev-libs/libusb-1.0.18" |
72 |
>>> |
73 |
>>> virtual/libusb-1-r1 depends on either dev-libs/libusb or |
74 |
>>> sys-freebsd/freebsd-lib. The latter one is only compatible |
75 |
>>> with libusb-1.0.9, so packages depending on |
76 |
>>> >dev-libs/libusb-1.0.9 can't use the virtual. |
77 |
>>> |
78 |
>>> Assuming freebsd-lib becomes compatible with dev-libs/libusb |
79 |
>>> again, packages will have to switch back to the virtual to |
80 |
>>> support both. |
81 |
>>> |
82 |
>>> Depending on virtual/libusb[>=dev-libs/libusb-1.0.18(+)] |
83 |
>>> instead would just need a change in the virtual. |
84 |
>> |
85 |
>> This sounds like something that should still be doable with two |
86 |
>> versions of the virtual/libusb package... I mean, if something |
87 |
>> *needs* a newer libusb than 1.0.9 , then it should appropriately |
88 |
>> depend on a virtual/libusb that needs it. Otherwise, it |
89 |
>> shouldn't matter which provider provides virtual/libusb-1 , |
90 |
>> right?? So we keep virtual/libusb-1 as-is, and add a |
91 |
>> virtual/libusb-1.0.10 (or whatever version is appropriate) for |
92 |
>> anything that needs a newer one. That newer one would need to |
93 |
>> have a !sys-freebsd/freebsd-lib in it, I think, to help keep it |
94 |
>> from being allowed to upgrade, but that itself might not be |
95 |
>> necessary. |
96 |
> |
97 |
> Not a blocker but rather lack of this dependency. We'll probably |
98 |
> have to mask it in bsd profiles as well but otherwise looks fine. |
99 |
> |
100 |
|
101 |
Just not including the sys-freebsd/freebsd-lib atom in the newer |
102 |
virtual generally makes sense, yes, but portage in particular will try |
103 |
to upgrade the virtual and therefore also switch the provider from |
104 |
freebsd-lib to the newer libusb on -uDN, right? A mask in profiles |
105 |
would do the trick (especially in this case due to there being two |
106 |
distinct sets of profiles for each provider) but it would be easier in |
107 |
the general case to handle this all in-ebuild if possible, wouldn't it? |
108 |
|
109 |
Back to my use flag suggestion -- this is an example that I don't |
110 |
think use flags could help; indeed i think the use flags would get in |
111 |
the way more than anything: #1, the newer version of the virtual |
112 |
would need to keep the flag for the missing provider to have any |
113 |
effect, and this just seems wrong; #2, the only flag-based blocking |
114 |
that could occur would be REQUIRED_USE or pkg_pretend, and both of |
115 |
those would keep an emerge -uDN @world from starting until resolved, |
116 |
instead of just disallowing the virtual from being upgraded. |
117 |
|
118 |
-----BEGIN PGP SIGNATURE----- |
119 |
Version: GnuPG v2 |
120 |
|
121 |
iF4EAREIAAYFAlPWaDQACgkQ2ugaI38ACPD3hQEArDTqKhKyys7lFDnKH6cyCLNu |
122 |
umPBhsTd1/vZQnijfgQA/3N9ry/LnTyeDyi0pSOqoEIODuYXCGQ7ksUslzQGTmzi |
123 |
=MKu7 |
124 |
-----END PGP SIGNATURE----- |