On 28 September 2013 23:36, Martin Vaeth
<va...@mathematik.uni-wuerzburg.de>wrote:
>
> 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)
The most annoying thing about that would be the implementation details.
The reason virtuals are such a nightmare for perl is really the way they're
oriented.
Every perl we release, we have to manually update "something", "somewhere"
in a location *other* than the perl ebuild itself.
Which means that instead of simply modifying perl's .ebuild, and walking
the contents of module::corelist and saying "This version provides X
version Y", one must instead have a way to reorient that data from the
perspective of dependencies.
That is, we must reorganize all the code in question in terms of X version
Y, as a list of things that provide that X version Y.
And thats the most no-trivial part of the equation.
The best solution I presently have for this problem, would be to have a
PROVIDES-${PV}.json file in every package under files/
That file would contain simply a list of provisions ( a literal string )
with a version of that provision.
And then we could mangle that data as an aggregate by iterating the whole
portage tree, collecting such files, and using them to provide the inverse
relationmap of "X verison Y is provided by Z version N", which could be
used by a suitable eclass.
Thats really as clean, and logical, as I can imagine making it. Just its
investment intensive, and investment intensive in ways that would be better
supported as a native portage feature.
--
Kent
