1 |
Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
> --001a11336248343a2604e7770011 |
3 |
> Content-Type: text/plain; charset=UTF-8 |
4 |
> |
5 |
> On 28 September 2013 23:36, Martin Vaeth |
6 |
><vaeth@××××××××××××××××××××××××.de>wrote: |
7 |
> |
8 |
>> |
9 |
>> Concerning the eclass idea which was already mentioned and |
10 |
>> which is perhaps even better than my suggeestion from the |
11 |
>> other posting, since it avoids some of the disadvantages: |
12 |
>> |
13 |
>> > by having an eclass that translates a special variable, say, |
14 |
>> > PERL_MODULE_COREDEPS="Term::ANSIColor@3.2" or something |
15 |
>> |
16 |
>> I would keep it simple like |
17 |
>> |
18 |
>> RDEPEND="$(perl-dep Term-ANSIColor) |
19 |
>> $(perl-dep ">=Module-Load-0.240.0")" |
20 |
|
21 |
It would have been wiser to suggest here the syntax |
22 |
perl-core/Term-ANSIColor and perl-core/Module-Load-0.240.0, |
23 |
respectively so that the category need not be fixed to |
24 |
"perl-core". |
25 |
|
26 |
>> |
27 |
>> which would then translate into something like |
28 |
>> |
29 |
>> RDEPEND="( || ( ( >=perl-5.12 <=perl-5.18.1 ) perl-core/Term-ANSIColor ) |
30 |
>> || ( >=perl-5.18 >=perl-core/Module-Load-0.240.0 )" |
31 |
>> |
32 |
>> (or "|| ( ( perl-5.12* perl-5.14* ... |
33 |
>> || ( perl-5.18* ...)" - |
34 |
>> subject to further discussion) |
35 |
> |
36 |
> |
37 |
> The most annoying thing about that would be the implementation details. |
38 |
|
39 |
Why? One of use probably misunderstand something: |
40 |
|
41 |
> Every perl we release, we have to manually update "something", "somewhere" |
42 |
> in a location *other* than the perl ebuild itself. |
43 |
|
44 |
If you decide to use the eclass, then with each perl release |
45 |
you would have to update the data in the eclass - namely the LIST of |
46 |
provided packages for that new version. Something like |
47 |
|
48 |
LIST_perl5.18=( |
49 |
perl-core/Term-ANSIColor-4.20 |
50 |
perl-core/...-... |
51 |
dev-perl/...-... |
52 |
!perl-core/X-Y |
53 |
!!perl-core/X-Y |
54 |
) |
55 |
LIST_perl5.16=( |
56 |
) |
57 |
... |
58 |
AVAILABLE_PERLS="5.18 5.16 ..." |
59 |
|
60 |
where the special symbols ! means that version perl-core/X-Y is |
61 |
not available in the tree and !! means that perl-core/X is not |
62 |
available in the tree (in no version). |
63 |
These LISTs are all which you have to update for new perl versions. |
64 |
The rest should be handled by the logic of the eclass, and I do not |
65 |
see why this should be hard to do: |
66 |
|
67 |
1. |
68 |
If perl-dep is called with the argument |
69 |
">=category/package-version", |
70 |
">category/package-version", |
71 |
"<=category/package-version", |
72 |
"<category/package-version", |
73 |
"=category/package-version", or |
74 |
"~category/package-version", |
75 |
the function just output into || ( ... ) all perl versions which provide |
76 |
a matching package according to LIST, followed by the passed argument |
77 |
(the latter is skipped, if masked by ! or !! according to one LIST). |
78 |
In case of "<=" or "<" in addition the blocker |
79 |
"!>category/package-version" or "!>=category/package-version" |
80 |
is output (unless masked by ! or !!). |
81 |
|
82 |
2. |
83 |
If perl-dep is called with the argument |
84 |
"catogory/package" |
85 |
(without a version) the function just adds into || ( ... ) all |
86 |
perl versions which provide the package and in addition ends with |
87 |
the passed argument (unless masked by !!). |
88 |
|
89 |
Implementation of that function is rather simple once you have |
90 |
a version comparison function (I do not remember in the moment |
91 |
whether this is already available in some eclass or will be |
92 |
only available the next EAPI). |
93 |
Of course, the output could be optimized by omitting the "|| ( )" symbols |
94 |
if there is only one match etc. |
95 |
|
96 |
> Which means that instead of simply modifying perl's .ebuild, and walking |
97 |
> the contents of module::corelist and saying "This version provides X |
98 |
> version Y", one must instead have a way to reorient that data from the |
99 |
> perspective of dependencies. |
100 |
|
101 |
Why? You update the eclasses LIST variables in one place when a new |
102 |
version of perl comes out. All functions needing a perl |
103 |
package use the perl-dep function (which means a one-shot change for |
104 |
all packages needing a perl package; for packages in the |
105 |
tree this can be done by the "script" I mentioned). |
106 |
|
107 |
> The best solution I presently have for this problem, would be to have |
108 |
> a PROVIDES-${PV}.json file in every package under files/ |
109 |
|
110 |
Not under files but in the eclass, and the rest of the |
111 |
work is done by the perl-dep function. |