Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico <zmedico@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 28 Sep 2008 15:11:42 -0700
> Zac Medico <zmedico@gentoo.org> 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-----