1 |
On Sun, 28 Sep 2008 15:56:27 -0700 |
2 |
Zac Medico <zmedico@g.o> wrote: |
3 |
> As I've tried to explain, the an ebuild which exhibits |
4 |
> PROPERTIES=set doesn't necessarily have to behave any differently |
5 |
> than a meta-package currently does. What we would do is create a |
6 |
> configuration that maps the set-property ebuild into set space. For |
7 |
> example, `emerge kde-meta` would behave as as normal meta-package |
8 |
> currently does, and `emerge @kde-meta` would reference the same |
9 |
> package as a set and could thereby trigger different behavior which |
10 |
> is appropriate for a set. |
11 |
|
12 |
...and what would that behaviour be? What does a PDEPEND mean for a |
13 |
set? |
14 |
|
15 |
> > Here's an alternate proposal: Repositories can ship sets via files |
16 |
> > in sets/*.conf. The format is as described in [1]. In configuration |
17 |
> > files, operations applied to a set are applied to anything matching |
18 |
> > any spec listed in that set (or any set that set contains, and so |
19 |
> > on). On the command line, sets and non-sets cannot be mixed, and |
20 |
> > multiple sets cannot be specified. |
21 |
> > |
22 |
> > [1]: http://paludis.pioto.org/configuration/sets.html |
23 |
> > |
24 |
> |
25 |
> Perhaps can use something like you've got there in addition to the |
26 |
> PROPERTIES=set approach. |
27 |
|
28 |
Why the need for multiple solutions at all? PROPERTIES=set is too weird |
29 |
and involves too much nonsensical behaviour to be useful. |
30 |
|
31 |
-- |
32 |
Ciaran McCreesh |