Following the current spec:
Ah, it may not be obvious from the comments, so: I updated the URL and the official spec is now at:
oh, please implement :D
Let's forget about trying to change the past EAPIs and just focus on bringing it to the next EAPI.
The IUSE_RUNTIME would be a separate variable. Flags would share the namespace with regular USE flags and collide with them if both declared in IUSE & IUSE_RUNTIME.
I see that I could also use this to decrease user pain when new Python implementations are introduced.
More specifically, python-single-r1 could do something like:
IUSE_RUNTIME="python_targets_python2_6 python_targets_python2_7 ..."
since those flags affect only dependencies and REQUIRED_USE constraints. Then, user could add python3_4 to PYTHON_TARGETS without getting all python-single-r1 packages rebuilt.
Similarly, random packages could use:
IUSE_RUNTIME="!python? ( python_targets_... )"
to 'ignore' PYTHON_TARGETS when USE=python is not enabled.
Ok, let's start by getting the goal clear. CC-ing dev-portage@ to help finding the correct wording.
I would go for rejecting GLEP 62. It was intended to allow getting runtime USE flags optionally in current EAPIs. Since we're doing that as part of EAPI 6, the feature should be described in PMS and the GLEP is therefore obsolete.
The rules for PMS should be as simple as possible. I'd say:
1. runtime-switchable USE flags are suffixed by special marker in IUSE, e.g.
2. List of runtime-switchable USE flags, associated dependencies and REQUIRED_USE constraints must be kept in installed package metadata.
3. Change of runtime-switchable USE flags does not change contents of installed package and therefore can be applied in-place after installing the necessary dependencies.
Note that this reduces the amount of magic to minimum. In particular:
1. there's no ebuild->vdb metadata transfer. Runtime USE flags and their dependencies are read from vdb, and the changes are applied there.
2. There's no implicit auto-enabling of flags. Flags have to be enabled normally, and '--changed-use' or '--newuse' needs to trigger the update. After dependencies are installed, the vdb entries for package are updated.
Question: should only '--newuse', '--changed-use' and indirect ebuild dependencies trigger runtime-USE updates? i.e. should 'emerge -1v foo' trigger a rebuild anyway?
(In reply to Michał Górny from comment #5)
> I would go for rejecting GLEP 62. It was intended to allow getting runtime
> USE flags optionally in current EAPIs. Since we're doing that as part of
> EAPI 6, the feature should be described in PMS and the GLEP is therefore
> Question: should only '--newuse', '--changed-use' and indirect ebuild
> dependencies trigger runtime-USE updates? i.e. should 'emerge -1v foo'
> trigger a rebuild anyway?
I hate to say it, but this should probably be posted to the dev ML.
Copying the question from bug 449862 comment 3 to here, so it won't get forgotten: Should the IUSE query function (see bug 449862) return true for the flags that are runtime switchable?
While there's certainly interest in having this, it won't go anywhere without somebody actually being able to implement it.
(In reply to Ulrich Müller from comment #7)
> Copying the question from bug 449862 comment 3 to here, so it won't get
> forgotten: Should the IUSE query function (see bug 449862) return true for
> the flags that are runtime switchable?
My guess would be 'no', given that you can't use them most of the time. Maybe adding an extra switch for this kind of flags would be desired.
(In reply to Michał Górny from comment #8)
> While there's certainly interest in having this, it won't go anywhere
> without somebody actually being able to implement it.
It is obvious that GLEPs for new EAPI features get more leeway for inactivity than the 60 days specified in GLEP 28. However, GLEP 62 was posted on 2012-07-11, with no changes (other than editorial) after that. The feature was deferred from EAPI 6 and rejected from EAPI 7. The NeedPatch keyword was added to this bug more than three years ago.
Therefore, I am going to mark GLEP 62 as Deferred. It can be reopened (per GLEP 28) when an implementation is under way.
The bug has been referenced in the following commit(s):
Author: Ulrich Müller <email@example.com>
AuthorDate: 2019-02-23 10:23:05 +0000
Commit: Ulrich Müller <firstname.lastname@example.org>
CommitDate: 2019-02-23 10:23:05 +0000
glep-0062: Deferred due to inactivity.
Signed-off-by: Ulrich Müller <email@example.com>
glep-0062.rst | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
*** Bug 201499 has been marked as a duplicate of this bug. ***
*** Bug 373323 has been marked as a duplicate of this bug. ***