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