| 1 |
On Sat, 29 Sep 2012 09:12:38 -0700 |
| 2 |
Zac Medico <zmedico@g.o> wrote: |
| 3 |
|
| 4 |
> On 09/29/2012 02:42 AM, Michał Górny wrote: |
| 5 |
> > Hello, |
| 6 |
> > |
| 7 |
> > Following the late discussion, I have updated GLEP-62. It no longer is |
| 8 |
> > designed to be 'backwards compatible' and instead it was suited for |
| 9 |
> > addition in a new EAPI. |
| 10 |
> > |
| 11 |
> > Thus, IUSE_RUNTIME is now independent of IUSE, and runtime dependencies |
| 12 |
> > can be expressed in SDEPEND only. |
| 13 |
> |
| 14 |
> Thanks, these changes make it much more manageable. Trying to do |
| 15 |
> something like this retroactively for existing EAPIs is just a mess. |
| 16 |
> |
| 17 |
> > There's still a case of REQUIRED_USE. I'm not really convinced to |
| 18 |
> > create a REQUIRED_RUNTIME_USE especially for it. Also, it may be |
| 19 |
> > actually better to put all IUSE_RUNTIME flags to IUSE as well -- since |
| 20 |
> > the package manager will after all be required to concatenate them |
| 21 |
> > anyway. |
| 22 |
> |
| 23 |
> Will runtime flags be able to interact with buildtime flags then? It |
| 24 |
> seems like it could be useful, so it we should probably allow it. Sure, |
| 25 |
> people could write some expressions that don't make sense, but that's |
| 26 |
> already the case with REQUIRED_USE. |
| 27 |
|
| 28 |
Yes, that's the intent, e.g. when a particular runtime feature requires |
| 29 |
another build-time feature. |
| 30 |
|
| 31 |
-- |
| 32 |
Best regards, |
| 33 |
Michał Górny |
Archives