On 29 September 2013 11:13, Martin Vaeth
<va...@mathematik.uni-wuerzburg.de>wrote:
>
> > The best solution I presently have for this problem, would be to have
> > a PROVIDES-${PV}.json file in every package under files/
>
> Not under files but in the eclass, and the rest of the
> work is done by the perl-dep function.
The reason I suggested that approach, is because a list of modules and
versions that are contained within a specific version of a specific
package, is ostensibly a property of that version of that package.
And thus, with it in ${FILESDIR}, updating $P to a new $V makes it easy to
check for the existence of a respective ${FILESDIR}/PROVIDES-{$PV}.json
And thus, the technique can be used, not only for all of dev-lang/perl, but
for all of perl-core/* , and possibly even dev-perl/* , and maybe even
things outside these categories that happen to be providers of perl modules.
Then, the relative content in the eclass/ tree could be generated from
that data, and generated in the inverse form, allowing $(perl-dep "some
string here") to have a unique mapping for all values of those strings, in
a form that was easy to decode and understand.
Thus, the conditionality of the dependency would not have to be determined
by messy bash code during the parsing of each and every ebuild, and would
instead be a relatively simple lookup table.
This moves all the overhead complexity from being something that only
happens in the developer side of things, reducing the number of ways the
eclass can fail.
And then we can also debate the qualities of specific ways of declaring the
dependency itself post-eclass, as it becomes a separate problem from how
the resolution is performed.
--
Kent
