Kent Fredric <kentfred...@gmail.com> 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.
This is only one view of things. One might also have the view that
it is a property of the packages depending on it whether they accept
that dependency. Only the latter view is supported by the current way
dependencies work.
> 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
Of course, if portage would support also the other view, it would be
nice, also from the user perspective:
For instance, if you have your home-brewn version of program X,
you can just install the version under its own package name Y and
make it satisfy all dependencies of X.
(Currently you have to mess around with package.provided which has
many drawbacks like e.g. problems with USE-dependencies and,
moreover, you cannot publish Y in an overlay without requiring
that the user of that overlay modifies his package.provided manually.)
However, I am afraid that this requires a rather fundamental rewrite
of the current dependency logic in package managers.
