| 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). |
Archives