-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 25 Sep 2012 12:19:21 -0400 Ian Stakenvicius <a...@gentoo.org> 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-----
