On Sun, 28 Sep 2008 15:11:42 -0700
Zac Medico <zmedico@g.o> wrote:
> > GLEP 37 effectively abolishes virtuals. It doesn't try to overload
> > new behaviour onto packages.
> 
> Well, PROPERTIES=set doesn't necessarily need overload new behavior
> onto packages any more that virtual ebuilds do. If set-property
> ebuilds are mapped into set space then the overloaded behavior will
> come from them being referenced as sets, which won't overload their
> ebuild behavior since they can simply behave like existing
> meta-packages already do.

Ok, so say we have cat/foo-1:

    PROPERTIES=""
    DEPEND="cat/one cat/two cat/three"
    RDEPEND="cat/two cat/four"

and cat/foo-2:

    PROPERTIES="set"
    DEPEND="cat/one cat/two cat/three"
    RDEPEND="cat/two cat/four"

Then what does this do in package.use?

    cat/foo monkey

What does this do in package.mask?

    cat/foo

What about this?

    >=cat/foo-2

What about this?

    <cat/foo-2

What does this do?

    emerge -uDpv cat/foo

What about this?

    emerge -uDpv \>=cat/foo-2

What about this?

    emerge -uDpv \<cat/foo-2

Now let's introduce cat/bar-1:

    DEPEND="cat/foo"

and cat/bar-2:

    DEPEND="=cat/foo-1"

What does this do?

    emerge -e cat/bar

What about:

    emerge -e =cat/bar-1

And how is this anything other than highly weird?

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

-- 
Ciaran McCreesh