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 |