| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Bo Ørsted Andresen wrote: |
| 5 |
> On Monday 29 September 2008 01:37:03 Zac Medico wrote: |
| 6 |
>>> Why the need for multiple solutions at all? PROPERTIES=set is too weird |
| 7 |
>>> and involves too much nonsensical behaviour to be useful. |
| 8 |
>> I don't see the PROPERTIES=set approach as being worse than any |
| 9 |
>> other approach for package set definition. It has lots of advantages |
| 10 |
>> because of the way that it fits into the existing ebuild framework |
| 11 |
>> like virtual ebuilds do [1], allowing it to leverage all of the |
| 12 |
>> existing features of the framework (including package.use) and also |
| 13 |
>> allowing it to leverage the tools that have been designed to work |
| 14 |
>> with the framework. |
| 15 |
>> |
| 16 |
>> [1] http://www.gentoo.org/proj/en/glep/glep-0037.html |
| 17 |
> |
| 18 |
> I really don't see the advantages of fitting 'into the existing ebuild |
| 19 |
> framework like virtual ebuilds do'. Can you name any real advantages to it? |
| 20 |
|
| 21 |
This idea initially came up when Jorge (jmbsvicetto) mentioned that |
| 22 |
he had used a package set to replace a meta-ebuild in the |
| 23 |
desktop-effects overlay, and then users complained that the set did |
| 24 |
not supporting the USE conditionals that the previous meta-ebuild |
| 25 |
had supported. |
| 26 |
|
| 27 |
Perhaps we can support USE conditionals in sets, but this also seems |
| 28 |
to mean that we will need a package.use analog that applies to |
| 29 |
package sets. Assuming that we'll need a package.use analog, we |
| 30 |
might view the act of replacing meta-packages with sets as a sort of |
| 31 |
"throwing the baby out with the bath water" scenario in sense that |
| 32 |
meta-packages have lots of useful features and the only reason to |
| 33 |
migrate them to sets would be take advantage of the unique features |
| 34 |
which sets have to offer. So, rather than force a complete |
| 35 |
migration, we may want to consider integrating meta-packages into |
| 36 |
the sets framework. |
| 37 |
|
| 38 |
> Having virtuals as ebuilds makes sense because ebuilds need to depend upon |
| 39 |
> them. But I can see no decent use case for letting a non-set ebuild depend |
| 40 |
> upon a set. As far as I'm concerned sets are merely a convenience for users. |
| 41 |
> It allows them to install, reinstall (mostly of interest for scm ebuilds), |
| 42 |
> keyword, unmask, set use flags for or uninstall a set of packages. |
| 43 |
|
| 44 |
The "set use flags" part is interesting. If that's the case, it |
| 45 |
seems somewhat ambiguous to use sets to "set use flags" and also |
| 46 |
allow sets to contain USE conditionals. Supposing that we do allow |
| 47 |
both, are we going to create some analog of package.use for sets, or |
| 48 |
not? If we do create such an analog, how would it apply to nested |
| 49 |
sets? Should nested sets be able to have separate USE conditional |
| 50 |
settings from the sets that nest them? |
| 51 |
- -- |
| 52 |
Thanks, |
| 53 |
Zac |
| 54 |
-----BEGIN PGP SIGNATURE----- |
| 55 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 56 |
|
| 57 |
iEYEARECAAYFAkjhMeIACgkQ/ejvha5XGaN5EgCgp/KWDienRceXkzV5GX4u9wZp |
| 58 |
oYEAnRZ7Z8BErZGRNe6muf7fPRLlW/bQ |
| 59 |
=RFAJ |
| 60 |
-----END PGP SIGNATURE----- |
Archives