1 |
Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
> |
3 |
> I mean, the reason virtuals suck is predominantly the fact we have to |
4 |
> update the conditionals to accurately reflect the version on the virtual |
5 |
|
6 |
Concerning the eclass idea which was already mentioned and |
7 |
which is perhaps even better than my suggeestion from the |
8 |
other posting, since it avoids some of the disadvantages: |
9 |
|
10 |
> by having an eclass that translates a special variable, say, |
11 |
> PERL_MODULE_COREDEPS="Term::ANSIColor@3.2" or something |
12 |
|
13 |
I would keep it simple like |
14 |
|
15 |
RDEPEND="$(perl-dep Term-ANSIColor) |
16 |
$(perl-dep ">=Module-Load-0.240.0")" |
17 |
|
18 |
which would then translate into something like |
19 |
|
20 |
RDEPEND="( || ( ( >=perl-5.12 <=perl-5.18.1 ) perl-core/Term-ANSIColor ) |
21 |
|| ( >=perl-5.18 >=perl-core/Module-Load-0.240.0 )" |
22 |
|
23 |
(or "|| ( ( perl-5.12* perl-5.14* ... |
24 |
|| ( perl-5.18* ...)" - |
25 |
subject to further discussion) |
26 |
|
27 |
Of course, perl-dep might also loop over its arguments... |
28 |
Transfer of current ebuilds into the new format would be trivial: |
29 |
s{(\S*)virtual/perl-(\S*)}{\$\(perl-dep \"$1$2\"\)}g |
30 |
(and adding the inherit if at least one match occured). |
31 |
|
32 |
> something I really want to avoid, mostly, because the massive amount of |
33 |
> moving parts required to implement such a feature. |
34 |
|
35 |
If the eclass is written generically you only have to fill in |
36 |
one list for each perl-version (further simplifications of the data |
37 |
format are thinkable) containg the provided packages e.g. in |
38 |
the form category/package-version |
39 |
If there is interest, I might volunteer to provide a first form |
40 |
of such an eclass (though I can make no promises in the moment). |