On Sun, 28 Sep 2008 15:56:27 -0700
Zac Medico <zmedico@g.o> wrote:
> As I've tried to explain, the an ebuild which exhibits
> PROPERTIES=set doesn't necessarily have to behave any differently
> than a meta-package currently does. What we would do is create a
> configuration that maps the set-property ebuild into set space. For
> example, `emerge kde-meta` would behave as as normal meta-package
> currently does, and `emerge @kde-meta` would reference the same
> package as a set and could thereby trigger different behavior which
> is appropriate for a set.

...and what would that behaviour be? What does a PDEPEND mean for a
set?

> > Here's an alternate proposal: Repositories can ship sets via files
> > in sets/*.conf. The format is as described in [1]. In configuration
> > files, operations applied to a set are applied to anything matching
> > any spec listed in that set (or any set that set contains, and so
> > on). On the command line, sets and non-sets cannot be mixed, and
> > multiple sets cannot be specified.
> > 
> > [1]: http://paludis.pioto.org/configuration/sets.html
> > 
> 
> Perhaps can use something like you've got there in addition to the
> PROPERTIES=set approach.

Why the need for multiple solutions at all? PROPERTIES=set is too weird
and involves too much nonsensical behaviour to be useful.

-- 
Ciaran McCreesh