| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Ciaran McCreesh wrote: |
| 5 |
> On Sun, 28 Sep 2008 13:53:12 -0700 |
| 6 |
> Zac Medico <zmedico@g.o> wrote: |
| 7 |
>>>> Does this seem like a good approach? Are there any suggestions for |
| 8 |
>>>> improvements or alternative approaches? |
| 9 |
>>> Strikes me as a good way of causing extreme confusion for users... |
| 10 |
>> Perhaps it's not so confusing if the packages continue to behave |
| 11 |
>> normally in the usual cases, but they are mapped into set space as |
| 12 |
>> suggested earlier [1]. |
| 13 |
> |
| 14 |
> Then why not just make the things sets? Come up with a standard way of |
| 15 |
> distributing sets as part of a repository, and let future EAPIs include |
| 16 |
> deps upon sets. |
| 17 |
|
| 18 |
We can even do both. We could come up with a standard way to |
| 19 |
distribute sets and make PROPERTIES=set be one of the possible |
| 20 |
formats used for set distribution. |
| 21 |
|
| 22 |
>>> Consider sets in package.use, for example. Any specified flags |
| 23 |
>>> should apply to the entire set. But what about set-property |
| 24 |
>>> packages? |
| 25 |
>> In order to fit into the ebuild framework, the specified flags would |
| 26 |
>> only apply to direct dependency atoms. Atoms pulled in by recursion |
| 27 |
>> into other set-property packages would have the flags applied from |
| 28 |
>> those respective set-property packages. |
| 29 |
> |
| 30 |
> Right, so you'd get the bizarre case that, given: |
| 31 |
> |
| 32 |
> cat/foo one |
| 33 |
> cat/bar two |
| 34 |
> cat/baz three |
| 35 |
> |
| 36 |
> The one flag applies onto to cat/foo, the three flag applies only to |
| 37 |
> cat/baz but the two flag applies to cat/monkey and cat/hamster. |
| 38 |
> |
| 39 |
> Sets need to *look* different... |
| 40 |
|
| 41 |
It seems like more of a feature to me, rather than a problem. The |
| 42 |
idea is that sets can nest other sets, and at the same time nested |
| 43 |
sets can have different USE conditional settings than the sets that |
| 44 |
nest them. |
| 45 |
|
| 46 |
>>> Sets and packages aren't the same thing, and shouldn't be treated |
| 47 |
>>> as if they are. |
| 48 |
>> Packages and virtuals aren't the same thing either, but glep 37 |
| 49 |
>> virtuals fit quite well into the existing ebuild framework. It seems |
| 50 |
>> to me that set-property packages will also fit nicely into the |
| 51 |
>> existing ebuild framework. |
| 52 |
> |
| 53 |
> GLEP 37 effectively abolishes virtuals. It doesn't try to overload new |
| 54 |
> behaviour onto packages. |
| 55 |
|
| 56 |
Well, PROPERTIES=set doesn't necessarily need overload new behavior |
| 57 |
onto packages any more that virtual ebuilds do. If set-property |
| 58 |
ebuilds are mapped into set space then the overloaded behavior will |
| 59 |
come from them being referenced as sets, which won't overload their |
| 60 |
ebuild behavior since they can simply behave like existing |
| 61 |
meta-packages already do. |
| 62 |
- -- |
| 63 |
Thanks, |
| 64 |
Zac |
| 65 |
-----BEGIN PGP SIGNATURE----- |
| 66 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 67 |
|
| 68 |
iEYEARECAAYFAkjgAR0ACgkQ/ejvha5XGaNmDQCfSO4J2fs2aaLHXZ9/MOABy6E1 |
| 69 |
654AnRDLDgJzWyyzzHX3ef5zIufePX62 |
| 70 |
=0GO8 |
| 71 |
-----END PGP SIGNATURE----- |
Archives