Following the current spec: https://gist.github.com/2945569
Ah, it may not be obvious from the comments, so: I updated the URL and the official spec is now at: http://www.gentoo.org/proj/en/glep/glep-0062.html
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. IUSE="foo(*)" 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 > obsolete. I agree. > ... All good. > 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): https://gitweb.gentoo.org/data/glep.git/commit/?id=4f0759fad6d30b4b31992d2bd96484741f01973e commit 4f0759fad6d30b4b31992d2bd96484741f01973e Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2019-02-23 10:23:05 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2019-02-23 10:23:05 +0000 glep-0062: Deferred due to inactivity. Bug: https://bugs.gentoo.org/424283 Signed-off-by: Ulrich Müller <ulm@gentoo.org> 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. ***
Please, reconsider this issue. The optfeature eclass, which has become a substitute solution to the problem, is functionally lacking and obnoxious. It's worse, in fact, than local USE flags, a practice currently in disfavor with the QA policy. Both the eclass and local flags notify me of the options. But the eclass does that every time there's an update of a package using it. That's useless and loud (KDE anyone?). Moreover, when I want an optional dep, I have to emerge it manually, keep it in @world and maintain a custom record somewhere of the reason why it is there. An official recommendation is to maintain a custom pkg set for that purpose. That's as inconvenient a solution as any. I then have to check every now and then whether each one of the pkgs in that set still has a reason to be in the system. With local USE flags I have to re-emerge every time I want a {different,} optional dep, but portage keeps track of the dep for me and removes it as soon as I remove the pkg which pulled it in. That's helpful. But more remarkably perhaps, the rebuild would rarely happen, because arguably, people rarely need to switch flags like this (precisely never in my case) and options are rarely added/removed. Please, abolish optfeature.eclass now in favor of local USE flags and possibly implement GLEP 62. I'm not posting here to support the GLEP, I haven't read it, but it would be a way out of optfeature.
