| 1 |
On Tue, Sep 18, 2012 at 08:48:16AM +0200, hasufell wrote: |
| 2 |
> I am unsure if that does or could solve the problem why GLEP 62 was |
| 3 |
> created, meaning... would enabling the "foo" useflag after the package |
| 4 |
> has been emerged trigger a remerge in the following example? |
| 5 |
> |
| 6 |
> DEPENDENCIES=" |
| 7 |
> dep:run? ( |
| 8 |
> foo? ( dev-libs/foobar ) |
| 9 |
> )" |
| 10 |
|
| 11 |
Just transfering over the discussion from IRC, tbh hadn't thought |
| 12 |
about it till you mentioned it since it has some potential flaws |
| 13 |
that aren't necessarily recoverable. |
| 14 |
|
| 15 |
Specifically, what happens if to enable dev-libs/foobar support, |
| 16 |
something has to be done at build time? Think about a systemd use |
| 17 |
flag, where the script just installs some configuration for systemd; |
| 18 |
that's not toggable. |
| 19 |
|
| 20 |
It's not obvious till you trace the implications through, but w/ |
| 21 |
those issues what you wind up with at that point is trying to |
| 22 |
classify use flags, ala glep62; see the past complete-ass-ripping of |
| 23 |
that proposal for why it doesn't fly. |
| 24 |
|
| 25 |
Just adding another; ebuild devs are completely up shit creek if the |
| 26 |
flag induces a build time effect in one spot, and controls optional |
| 27 |
deps in another section of the dep tree. |
| 28 |
|
| 29 |
If someone sees a way to make that work, have at it, although to be |
| 30 |
clear any such notion I'm intentionally leaving out of my proposal |
| 31 |
since I don't see a way to do it without an explicit dep labeling. |
| 32 |
|
| 33 |
~harring |
Archives