1 |
Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
>> |
3 |
>> > The best solution I presently have for this problem, would be to have |
4 |
>> > a PROVIDES-${PV}.json file in every package under files/ |
5 |
>> |
6 |
>> Not under files but in the eclass, and the rest of the |
7 |
>> work is done by the perl-dep function. |
8 |
> |
9 |
> The reason I suggested that approach, is because a list of modules and |
10 |
> versions that are contained within a specific version of a specific |
11 |
> package, is ostensibly a property of that version of that package. |
12 |
|
13 |
This is only one view of things. One might also have the view that |
14 |
it is a property of the packages depending on it whether they accept |
15 |
that dependency. Only the latter view is supported by the current way |
16 |
dependencies work. |
17 |
|
18 |
> And thus, with it in ${FILESDIR}, updating $P to a new $V makes it easy to |
19 |
> check for the existence of a respective ${FILESDIR}/PROVIDES-{$PV}.json |
20 |
|
21 |
Of course, if portage would support also the other view, it would be |
22 |
nice, also from the user perspective: |
23 |
|
24 |
For instance, if you have your home-brewn version of program X, |
25 |
you can just install the version under its own package name Y and |
26 |
make it satisfy all dependencies of X. |
27 |
(Currently you have to mess around with package.provided which has |
28 |
many drawbacks like e.g. problems with USE-dependencies and, |
29 |
moreover, you cannot publish Y in an overlay without requiring |
30 |
that the user of that overlay modifies his package.provided manually.) |
31 |
|
32 |
However, I am afraid that this requires a rather fundamental rewrite |
33 |
of the current dependency logic in package managers. |