Re: [gentoo-dev] Addressing GLEP-62 itself

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/09/12 02:03 PM, Ian Stakenvicius wrote:
> 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.
>
> 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.
>
> IE2, shouldn't the original ebuild be what's used to trigger the
> skip-rebuild functionality, rather than the in-tree ebuild?
>
>
> #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.
>
> In order to properly handle dependency resolution (which IMO we
> should do, because these are still USE flags) I think all use flag
> settings should still be honoured by the PM and related metadata in
> the vdb be updated for IUSE_RUNTIME flags identically to how it
> would be done if IUSE_RUNTIME wasn't set.
>
>
> Thoughts?
>


Based on the above I do expect the reference implementation would also
need to change.  I expect, for instance, that the PM's
metadata-handling would need to occur as normal even though none of
the package's phase functions would run, that is, *DEPEND
(realistically RDEPEND as that should be the only one affected here,
maybe PDEPEND too) and USE/PKGUSE would get updated.  Since portage
would not be re-emerging the package from the tree the original ebuild
would remain.

I expect, as a corollary to this, that a rebuild would be necessary if
(on-disk-IUSE_RUNTIME xor in-ebuild-IUSE_RUNTIME) was non-empty
(--newuse) or resulted in any flags that are in USE
(--reinstall=changed-use).  IMO this would be necessary to ensure the
local ebuild copy and all related metadata for it gets updated in vdb.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBh/EUACgkQ2ugaI38ACPAFfAD/UsYVQg6ZkwlsaWIafuFr0sqC
7IuvqIgroxNWJ/5XRS8BAJ+5awXZanZftOmFWRmDUAxOvPc8+J073dAn78N0CPdB
=zKzg
-----END PGP SIGNATURE-----