-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 28 Sep 2008 13:53:12 -0700 > Zac Medico <[EMAIL PROTECTED]> wrote: >>>> Does this seem like a good approach? Are there any suggestions for >>>> improvements or alternative approaches? >>> Strikes me as a good way of causing extreme confusion for users... >> Perhaps it's not so confusing if the packages continue to behave >> normally in the usual cases, but they are mapped into set space as >> suggested earlier [1]. > > Then why not just make the things sets? Come up with a standard way of > distributing sets as part of a repository, and let future EAPIs include > deps upon sets.
We can even do both. We could come up with a standard way to distribute sets and make PROPERTIES=set be one of the possible formats used for set distribution. >>> Consider sets in package.use, for example. Any specified flags >>> should apply to the entire set. But what about set-property >>> packages? >> In order to fit into the ebuild framework, the specified flags would >> only apply to direct dependency atoms. Atoms pulled in by recursion >> into other set-property packages would have the flags applied from >> those respective set-property packages. > > Right, so you'd get the bizarre case that, given: > > cat/foo one > cat/bar two > cat/baz three > > The one flag applies onto to cat/foo, the three flag applies only to > cat/baz but the two flag applies to cat/monkey and cat/hamster. > > Sets need to *look* different... It seems like more of a feature to me, rather than a problem. The idea is that sets can nest other sets, and at the same time nested sets can have different USE conditional settings than the sets that nest them. >>> Sets and packages aren't the same thing, and shouldn't be treated >>> as if they are. >> Packages and virtuals aren't the same thing either, but glep 37 >> virtuals fit quite well into the existing ebuild framework. It seems >> to me that set-property packages will also fit nicely into the >> existing ebuild framework. > > 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. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjgAR0ACgkQ/ejvha5XGaNmDQCfSO4J2fs2aaLHXZ9/MOABy6E1 654AnRDLDgJzWyyzzHX3ef5zIufePX62 =0GO8 -----END PGP SIGNATURE-----
