1 |
On 09/27/2012 01:30 PM, Ian Stakenvicius wrote: |
2 |
> On 27/09/12 04:13 PM, Zac Medico wrote: |
3 |
>> On 09/27/2012 12:53 PM, Brian Harring wrote: |
4 |
>>> Bullshit. This is optional in the sense of embrace/extend |
5 |
>>> 'optional'; if one PM takes up the new functionality, all have to |
6 |
>>> switch to writing unfinalized deps to the VDB, and all have to |
7 |
>>> switch to transfering that IUSE_RUNTIME crap to the VDB. |
8 |
> |
9 |
>> I think the proposal suddenly becomes a lot saner if it's done as |
10 |
>> an EAPI extension, the optional runtime deps and IUSE_RUNTIME |
11 |
>> conditionals are isolated in a new separate variable (perhaps |
12 |
>> SRDEPEND), and IUSE_RUNTIME is not allowed to intersect with IUSE. |
13 |
>> Using a separate SRDEPEND variable means that the package manager |
14 |
>> only has to preserve USE conditionals in the vdb for that one |
15 |
>> variable. |
16 |
> |
17 |
> |
18 |
> Saner, perhaps, but that would also mean the feature would be more or |
19 |
> less independent of the current USE handling within the PM. |
20 |
|
21 |
Well, the package manager could still treat IUSE_RUNTIME flags as valid |
22 |
flags for things like USE deps in _other_ packages. So, they don't have |
23 |
to be entirely independent. The idea is just to limit the scope where |
24 |
those flags are allowed the package that declares the flags as runtime |
25 |
flags, so that those runtime flags are only allowed in SRDEPEND. |
26 |
|
27 |
> Mind you if it's easier to deal with in the PM then I guess |
28 |
> piggy-backing on the current USE implementation isn't an advantage. |
29 |
|
30 |
Part of my concern is not just the implementation details, but also |
31 |
being able to explain/document for communication purposes. If it's such |
32 |
a mess that it's difficult to communicate, then it sucks for everyone |
33 |
involved. |
34 |
-- |
35 |
Thanks, |
36 |
Zac |