On Tue, 25 Sep 2012 14:03:36 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Since hasufell brought it up, and as I believe he's going to ask Council
> to approve it before moving forward with this proposal towards including
> it in an EAPI, I wanted to clarify some of the points mentioned:
> 
> - --- Quote, GLEP-62 ---
> > Specifications, paragraph 3: The package manager should treat flags
> > listed in IUSE_RUNTIME as regular USE flags, except for the 
> > following:
> > 
> > 1. enabling or disabling any of the flags must not involve 
> > rebuilding the package,
> > 
> > 2. it should be possible for a package manager to change those 
> > flags on a installed package without using the original ebuild,
> > 
> > 3. when queried on a installed package, the package manager must 
> > consider a particular flag enabled only if its dependencies are 
> > satisfied already,
> > 
> > 4. the flags may be listed in the visual output in a distinct way 
> > to inform the user that they affect runtime dependencies only.
> 
> 
> #2 -- this would, if I'm understanding it properly, mean that the IUSE
> list and the IUSE_RUNTIME list in the 'original ebuild' (ie in vdb)
> would be ignored on an emerged package in favour of the ebuild(s) in
> the tree, right?  I'm not so sure this is a good idea.

The exact opposite. The PM should use vdb whenever no non-IUSE_RUNTIME
flags have changed in vdb and no other reasons have caused it to use
the ebuild repository.

> IE, if IUSE and IUSE_RUNTIME have changed in the in-tree ebuild and
> one of those use flags that changed have been triggered or
> de-triggered I expect that the package should be rebuilt, to keep it
> consistent with current practices.

If --newuse triggers that, the ebuild will be used.

> IE2, shouldn't the original ebuild be what's used to trigger the
> skip-rebuild functionality, rather than the in-tree ebuild?

I already said that :).

> #3 -- this seems to imply to me, that the state of a package's
> effective USE could be modified solely on the basis of a dependency
> existing or not and have nothing to do with what the flag was set to
> at emerge time.  IE, *not* the state of USE in the vdb.  I think this
> would also be a problem.

No, you're overestimating it. It just means that the package manager
should first install the dependencies, and then update USE in vdb,
and not the other way around.

-- 
Best regards,
Michał Górny