On Monday 29 September 2008 01:37:03 Zac Medico wrote: > > Why the need for multiple solutions at all? PROPERTIES=set is too weird > > and involves too much nonsensical behaviour to be useful. > > I don't see the PROPERTIES=set approach as being worse than any > other approach for package set definition. It has lots of advantages > because of the way that it fits into the existing ebuild framework > like virtual ebuilds do [1], allowing it to leverage all of the > existing features of the framework (including package.use) and also > allowing it to leverage the tools that have been designed to work > with the framework. > > [1] http://www.gentoo.org/proj/en/glep/glep-0037.html
I really don't see the advantages of fitting 'into the existing ebuild framework like virtual ebuilds do'. Can you name any real advantages to it? Having virtuals as ebuilds makes sense because ebuilds need to depend upon them. But I can see no decent use case for letting a non-set ebuild depend upon a set. As far as I'm concerned sets are merely a convenience for users. It allows them to install, reinstall (mostly of interest for scm ebuilds), keyword, unmask, set use flags for or uninstall a set of packages. -- Bo Andresen
signature.asc
Description: This is a digitally signed message part.
