| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Ciaran McCreesh wrote: |
| 5 |
> On Sun, 28 Sep 2008 15:56:27 -0700 |
| 6 |
> Zac Medico <zmedico@g.o> wrote: |
| 7 |
>> As I've tried to explain, the an ebuild which exhibits |
| 8 |
>> PROPERTIES=set doesn't necessarily have to behave any differently |
| 9 |
>> than a meta-package currently does. What we would do is create a |
| 10 |
>> configuration that maps the set-property ebuild into set space. For |
| 11 |
>> example, `emerge kde-meta` would behave as as normal meta-package |
| 12 |
>> currently does, and `emerge @kde-meta` would reference the same |
| 13 |
>> package as a set and could thereby trigger different behavior which |
| 14 |
>> is appropriate for a set. |
| 15 |
> |
| 16 |
> ...and what would that behaviour be? What does a PDEPEND mean for a |
| 17 |
> set? |
| 18 |
|
| 19 |
Like virtuals, it makes sense to restrict the dependencies to the |
| 20 |
RDEPEND variable as mentioned in glep 37 [1]. I should have |
| 21 |
mentioned this earlier since it might not be obvious to some. |
| 22 |
|
| 23 |
>>> Here's an alternate proposal: Repositories can ship sets via files |
| 24 |
>>> in sets/*.conf. The format is as described in [1]. In configuration |
| 25 |
>>> files, operations applied to a set are applied to anything matching |
| 26 |
>>> any spec listed in that set (or any set that set contains, and so |
| 27 |
>>> on). On the command line, sets and non-sets cannot be mixed, and |
| 28 |
>>> multiple sets cannot be specified. |
| 29 |
>>> |
| 30 |
>>> [1]: http://paludis.pioto.org/configuration/sets.html |
| 31 |
>>> |
| 32 |
>> Perhaps can use something like you've got there in addition to the |
| 33 |
>> PROPERTIES=set approach. |
| 34 |
> |
| 35 |
> Why the need for multiple solutions at all? PROPERTIES=set is too weird |
| 36 |
> and involves too much nonsensical behaviour to be useful. |
| 37 |
|
| 38 |
I don't see the PROPERTIES=set approach as being worse than any |
| 39 |
other approach for package set definition. It has lots of advantages |
| 40 |
because of the way that it fits into the existing ebuild framework |
| 41 |
like virtual ebuilds do [1], allowing it to leverage all of the |
| 42 |
existing features of the framework (including package.use) and also |
| 43 |
allowing it to leverage the tools that have been designed to work |
| 44 |
with the framework. |
| 45 |
|
| 46 |
[1] http://www.gentoo.org/proj/en/glep/glep-0037.html |
| 47 |
- -- |
| 48 |
Thanks, |
| 49 |
Zac |
| 50 |
-----BEGIN PGP SIGNATURE----- |
| 51 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 52 |
|
| 53 |
iEYEARECAAYFAkjgFR4ACgkQ/ejvha5XGaNA5ACfUkefckOusoqkcSFgllZ6gSXu |
| 54 |
AP0AoNA4e/r5VxPtdDZtQRTzWDWZIa0U |
| 55 |
=GhAY |
| 56 |
-----END PGP SIGNATURE----- |
Archives