Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



On Tue, 25 Sep 2012 12:19:21 -0400

Ian Stakenvicius <axs@g.o> wrote:

> > a) How do we provide a good user interface for it? It took an awful
> > lot of experimenting to get the exheres-0 suggestions user
> > interface to be good, and it requires quite a bit more information
> > from the package side than this proposal is providing. We want to
> > avoid a REQUIRED_USE here...
>
> Standard USE flag interface.  This doesn't need anything special.  Why
> will a user care if the flag doesn't trigger a package rebuild?


One of the big selling points of suggestions is displaying them to the

user in a useful way (i.e. not via a bunch of einfo messages). If

you're not planning to allow for that, then you're losing a primary

benefit.



> > b) How is consistency checking to be done? Related, what happens
> > when a runtime switch introduces a dependency that then requires a
> > non-runtime rebuild of the original package?
>
> flag needs to be dropped from IUSE_RUNTIME, so the rebuild would
> occur.


Uh, you're requiring ebuilds to ensure consistency of every

possible configuration of the entire tree?



> > c) How do we deal with flag? ( cat/dep[foo] ) or flag? (
> > >=cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is
> > installed and flag is off? From experience, quite a few places
> > where you'd want to use suggestions will break if their suggested
> > package is installed but doesn't meet version or use requirements.
>
> Use flag deps are dealt with identically to the way they are now.  the
> only difference , again, is that the package doesn't get re-emerged.
> The VDB would still update imo as if the package did get re-emerged
> (ie:  USE and RDEPEND would update), to handle the use flag change
> info in metadata but from what I can tell nothing else would need to
> be touched.


So such packages would just break at runtime?



> > However, addressing these probably isn't enough, since this is
> > just the things we had to think about for SDEPEND-style
> > suggestions... There are likely to be things I've not thought of
> > specific to this method that won't crop up until someone tries to
> > deliver a decent implementation. This isn't a trivial feature.
>
> ..it really is.  It piggy backs entirely on the current USE
> implementation, and only skips triggering rebuilds because the
> files-on-disk for a package don't need to change.


It's only trivial if you don't try to do anything with it...



- -- 

Ciaran McCreesh

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.19 (GNU/Linux)



iEYEARECAAYFAlBh2xgACgkQ96zL6DUtXhGyFwCfYnK+RGbE+bR1Y53t/X3P7UKb

OW4An3fjTeXsXaksDTSAwf/yENunCGpC

=bWvu

-----END PGP SIGNATURE-----