1 |
On 29 September 2013 11:13, Martin Vaeth |
2 |
<vaeth@××××××××××××××××××××××××.de>wrote: |
3 |
|
4 |
> |
5 |
> > The best solution I presently have for this problem, would be to have |
6 |
> > a PROVIDES-${PV}.json file in every package under files/ |
7 |
> |
8 |
> Not under files but in the eclass, and the rest of the |
9 |
> work is done by the perl-dep function. |
10 |
|
11 |
|
12 |
The reason I suggested that approach, is because a list of modules and |
13 |
versions that are contained within a specific version of a specific |
14 |
package, is ostensibly a property of that version of that package. |
15 |
|
16 |
And thus, with it in ${FILESDIR}, updating $P to a new $V makes it easy to |
17 |
check for the existence of a respective ${FILESDIR}/PROVIDES-{$PV}.json |
18 |
|
19 |
And thus, the technique can be used, not only for all of dev-lang/perl, but |
20 |
for all of perl-core/* , and possibly even dev-perl/* , and maybe even |
21 |
things outside these categories that happen to be providers of perl modules. |
22 |
|
23 |
Then, the relative content in the eclass/ tree could be generated from |
24 |
that data, and generated in the inverse form, allowing $(perl-dep "some |
25 |
string here") to have a unique mapping for all values of those strings, in |
26 |
a form that was easy to decode and understand. |
27 |
|
28 |
Thus, the conditionality of the dependency would not have to be determined |
29 |
by messy bash code during the parsing of each and every ebuild, and would |
30 |
instead be a relatively simple lookup table. |
31 |
|
32 |
This moves all the overhead complexity from being something that only |
33 |
happens in the developer side of things, reducing the number of ways the |
34 |
eclass can fail. |
35 |
|
36 |
And then we can also debate the qualities of specific ways of declaring the |
37 |
dependency itself post-eclass, as it becomes a separate problem from how |
38 |
the resolution is performed. |
39 |
|
40 |
-- |
41 |
Kent |