-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > 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?
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. > 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. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjgC5oACgkQ/ejvha5XGaP0XwCdGbv7hIybD0k+GwRDTmyum3yY kusAoIs4Imz4tNtb18srdk3VzJM/+ZHJ =h5ii -----END PGP SIGNATURE-----
