| 1 |
On 28 September 2013 23:36, Martin Vaeth |
| 2 |
<vaeth@××××××××××××××××××××××××.de>wrote: |
| 3 |
|
| 4 |
> |
| 5 |
> Concerning the eclass idea which was already mentioned and |
| 6 |
> which is perhaps even better than my suggeestion from the |
| 7 |
> other posting, since it avoids some of the disadvantages: |
| 8 |
> |
| 9 |
> > by having an eclass that translates a special variable, say, |
| 10 |
> > PERL_MODULE_COREDEPS="Term::ANSIColor@3.2" or something |
| 11 |
> |
| 12 |
> I would keep it simple like |
| 13 |
> |
| 14 |
> RDEPEND="$(perl-dep Term-ANSIColor) |
| 15 |
> $(perl-dep ">=Module-Load-0.240.0")" |
| 16 |
> |
| 17 |
> which would then translate into something like |
| 18 |
> |
| 19 |
> RDEPEND="( || ( ( >=perl-5.12 <=perl-5.18.1 ) perl-core/Term-ANSIColor ) |
| 20 |
> || ( >=perl-5.18 >=perl-core/Module-Load-0.240.0 )" |
| 21 |
> |
| 22 |
> (or "|| ( ( perl-5.12* perl-5.14* ... |
| 23 |
> || ( perl-5.18* ...)" - |
| 24 |
> subject to further discussion) |
| 25 |
|
| 26 |
|
| 27 |
|
| 28 |
The most annoying thing about that would be the implementation details. |
| 29 |
|
| 30 |
The reason virtuals are such a nightmare for perl is really the way they're |
| 31 |
oriented. |
| 32 |
|
| 33 |
Every perl we release, we have to manually update "something", "somewhere" |
| 34 |
in a location *other* than the perl ebuild itself. |
| 35 |
|
| 36 |
Which means that instead of simply modifying perl's .ebuild, and walking |
| 37 |
the contents of module::corelist and saying "This version provides X |
| 38 |
version Y", one must instead have a way to reorient that data from the |
| 39 |
perspective of dependencies. |
| 40 |
|
| 41 |
That is, we must reorganize all the code in question in terms of X version |
| 42 |
Y, as a list of things that provide that X version Y. |
| 43 |
|
| 44 |
And thats the most no-trivial part of the equation. |
| 45 |
|
| 46 |
The best solution I presently have for this problem, would be to have a |
| 47 |
PROVIDES-${PV}.json file in every package under files/ |
| 48 |
|
| 49 |
That file would contain simply a list of provisions ( a literal string ) |
| 50 |
with a version of that provision. |
| 51 |
|
| 52 |
And then we could mangle that data as an aggregate by iterating the whole |
| 53 |
portage tree, collecting such files, and using them to provide the inverse |
| 54 |
relationmap of "X verison Y is provided by Z version N", which could be |
| 55 |
used by a suitable eclass. |
| 56 |
|
| 57 |
Thats really as clean, and logical, as I can imagine making it. Just its |
| 58 |
investment intensive, and investment intensive in ways that would be better |
| 59 |
supported as a native portage feature. |
| 60 |
|
| 61 |
-- |
| 62 |
Kent |
Archives