1 |
On 3 April 2015 at 06:32, Rich Freeman <rich0@g.o> wrote: |
2 |
|
3 |
> Why is this necessary? If a USE flag changes, just rebuild the |
4 |
> application. |
5 |
> |
6 |
|
7 |
|
8 |
Isn't the nature of your proposal,( that is, dynamic deps for USE flags ) |
9 |
inherently "Use flags change, _dont_ rebuild the application" ? :) |
10 |
|
11 |
It may help to think in terms of : Any ebuild without IUSE="foo" , once |
12 |
installed, actually has a property of USE_foo=undef |
13 |
|
14 |
Once an ebuild has IUSE="foo", the installed package then can subsequently |
15 |
get |
16 |
|
17 |
USE_foo=y |
18 |
USE_foo=n |
19 |
|
20 |
|
21 |
So under that logic, adding a new IUSE implies "Use flag changes" ( either |
22 |
from state undef to y , or state undef to n ). |
23 |
|
24 |
We have mechanisms for other ebuilds to declare what USE_foo=undef means in |
25 |
dependency defaults: |
26 |
|
27 |
>=X[foo(+)] # Assume USE_foo = undef to mean USE_foo = y |
28 |
>=X[foo(-)] # Assume USE_foo = undef to mean USE_foo = n |
29 |
|
30 |
There's just no mechanism similar to that for an ebuild with CVS revision |
31 |
02 to declare what USE_foo = undef meant on ebuild with CVS revision 01 |
32 |
|
33 |
|
34 |
Nor is there a way to express what USE_foo=undef meant on X<$PV |
35 |
|
36 |
|
37 |
|
38 |
( And subsequently, there is no user visible way /in portage/ for portage |
39 |
to express the meaning of a new USE flag becoming visible ) |
40 |
|
41 |
So I'm basically having trouble with groking the logic you're proposing of |
42 |
"add a new use flag" -> "implied change of useflag" -> "rebuild when |
43 |
useflags change" -> "but don't rebuild for this useflag change using some |
44 |
kind of magic" |
45 |
|
46 |
( Mostly due to the implied-change via addition I can't seem to ignore ) |
47 |
|
48 |
|
49 |
-- |
50 |
Kent |
51 |
|
52 |
*KENTNL* - https://metacpan.org/author/KENTNL |