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