On Tue, 25 Sep 2012 14:03:36 -0400 Ian Stakenvicius <a...@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
signature.asc
Description: PGP signature
