1 |
Zac Medico schrieb: |
2 |
>> Would it make sense to do the following: |
3 |
>> (1) make all new-style virtuals additionally depend on an old-style |
4 |
>> virtual (a new category might be appropriate) |
5 |
>> (2) ebuilds in overlays can PROVIDE the old-style virtual |
6 |
>> |
7 |
> It seems like new-style virtual would be introducing complexity without |
8 |
> adding any value here. Why not just use a pure old-style virtual? |
9 |
> |
10 |
|
11 |
The idea is that code for old-style virtuals can be removed from the |
12 |
package manager (which seems to be one of the goals of getting rid of |
13 |
old-style virtuals). |
14 |
|
15 |
>> (3) in a future EAPI, package managers are allowed to ignore the |
16 |
>> old-style virtual dependency for packages which are not already installed |
17 |
>> |
18 |
> I'm not sure what you mean here. In || dependencies, it's normal to |
19 |
> ignore choices that are masked or unavailable, so I'm not sure that |
20 |
> you're suggesting anything different from the existing || behavior. |
21 |
> |
22 |
|
23 |
Indeed, the old-style virtual will be a non-existing package in the case |
24 |
of a package manager which doesn't support them. |
25 |
|
26 |
>> If directly including installed old-style virtual packages in the |
27 |
>> dependency calculations is not feasible, (3) could be implemented |
28 |
>> through modifying package.provided like it is already done for |
29 |
>> package.{keywords,mask,use} after profile/ updates |
30 |
>> |
31 |
> Again, I'm not sure that I understand the point of this. Since || |
32 |
> dependencies already ignore unavailable or masked choices, why would |
33 |
> package.provided be needed? |
34 |
> |
35 |
|
36 |
Because the package manager might not know about old-style virtuals |
37 |
during dependency calculation. |
38 |
|
39 |
|
40 |
Regards, |
41 |
Chi-Thanh Christopher Nguyen |