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