1 |
Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
>> |
3 |
>> 1. The virtual does not even exist :) |
4 |
>> |
5 |
> |
6 |
> Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0 |
7 |
|
8 |
In this case the virtual is buggy, becaues it does not contain |
9 |
|| ( dev-lang/perl-5.18* ... ) |
10 |
|
11 |
Due to this, this particular example is not so ideal: I wanted to |
12 |
have an example where the stable virtual/perl-... version is higher |
13 |
than the one provided by (stable) perl. (This is then not the case |
14 |
once the virtual got fixed and perl-5.18 gets stable.) |
15 |
Please replace this example by one for which this is the case, say |
16 |
|
17 |
virtual/perl-Digest-MD5 |
18 |
|
19 |
and assume that I want an ebuild for a package for which *any* version |
20 |
of perl-Digest-MD5 would be sufficient. |
21 |
In this (now hopefully correct) example, if I do not write |
22 |
something like |
23 |
|
24 |
RDEPEND="|| ( >=dev-lang/perl-5.12 virtual/perl-Digest-MD5 )" |
25 |
|
26 |
or |
27 |
|
28 |
RDEPEND="|| ( =dev-lang/perl-5.12* ... virtual/perl-Digest-MD5 )" |
29 |
|
30 |
but instead only the "natural" |
31 |
|
32 |
RDEPEND="virtual/perl-Digest-MD5" |
33 |
|
34 |
I would currently pull in unnecessarily perl-core/Digest-MD5-2.520.0 |
35 |
or perl-core/Digest-MD5-2.530.0 (depending on whether the user |
36 |
is using e.g. ~amd64 or amd64). |
37 |
|
38 |
What I meant was that one might have the strange idea to use |
39 |
as a "workaround" for this problem the dependency |
40 |
|
41 |
RDEPEND="=virtual/perl-Digest-MD5-2.510.0-r2" |
42 |
|
43 |
but this would be a very bad idea many reasons, in particular: |
44 |
|
45 |
>> 2. It would collide with ebuilds depending on other versions. |
46 |
> |
47 |
> Nope, it would only collide in the case other ebuilds depended on a |
48 |
> specific version |
49 |
|
50 |
This is what I mean by "ebuilds depending on other versions". |
51 |
The above "workaround" would unnecessarily block ebuilds which |
52 |
contain |
53 |
|
54 |
RDEPEND="... >=virtual/perl-Digest-MD5-2.520.0 " |
55 |
|
56 |
> This is seen as a "feature" |
57 |
|
58 |
I agree. I just wanted to point out why the "workaround" is not |
59 |
really a workaround of the problem but would be just a very |
60 |
bad idea. |
61 |
|
62 |
>> 3. This version is only reasonable if perl-5.16 is the |
63 |
>> perl version which the user has installed |
64 |
> |
65 |
> And when perl 5.18 hits tree [...] you'll |
66 |
> need to change your dependency string in your package |
67 |
|
68 |
Exactly: This is what you would have to do, and which is not solved |
69 |
by the current virtual/... approach unless you accept pulling |
70 |
in unneeded dependencies. |
71 |
|
72 |
> Virtuals are much more convenient here |
73 |
|
74 |
More convient than putting into the ebuild, but at the cost |
75 |
not only of maintaining the virtuals but also of installing |
76 |
duplicate packages on the user's system. |
77 |
Take the above (hopefully correct) example that you |
78 |
have the "natural" |
79 |
|
80 |
RDEPEND="virtual/perl-Digest-MD5" |
81 |
|
82 |
Although *any* perl version containing this module would be |
83 |
sufficient, this dependency will install for a user with |
84 |
unstable keywords in addition perl-core/Digest-MD5-2.330.0, |
85 |
because this is the currently highest available version of |
86 |
the virtual and not satisfied by any perl version. |
87 |
(Similarly for the user with stable keywords, it will |
88 |
install currently unnecessarily perl-core/Digest-MD5-2.320.0 |
89 |
and when perl-5.18 hits the stable tree, it is rather likely |
90 |
that also >=virtual/Digest-MD5-2.330.0 is stable so that the |
91 |
user has unnecessary duplicate versions installed throughout.) |
92 |
|
93 |
> (Actually, thats a bug still, because corelist -a says 4.20.0 should be |
94 |
> available in 5.18 |
95 |
|
96 |
In my local overlay, I have a list of ~30 more such virtual/perl-* |
97 |
for which I have fixed dependencies (though maybe I have falsely |
98 |
translated the version numbers). This does not belong to this |
99 |
mailinglist, so if I you are interested in the virtual list or if |
100 |
I should open a bug, drop me a pm. |
101 |
|
102 |
Both suggested solutions (eclass or dev-lang/perl-... with useflags) |
103 |
would avoid all of these problem: |
104 |
|
105 |
You have to update only one list of packages for every perl version, |
106 |
not update every single virtual/... and, more important, the |
107 |
dependencies would not pull in unnecessary packages for the user. |