On Sun, 28 Sep 2008 15:56:27 -0700 Zac Medico <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
