1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Ciaran McCreesh wrote: |
5 |
> On Sun, 28 Sep 2008 15:11:42 -0700 |
6 |
> Zac Medico <zmedico@g.o> wrote: |
7 |
>>> GLEP 37 effectively abolishes virtuals. It doesn't try to overload |
8 |
>>> new behaviour onto packages. |
9 |
>> Well, PROPERTIES=set doesn't necessarily need overload new behavior |
10 |
>> onto packages any more that virtual ebuilds do. If set-property |
11 |
>> ebuilds are mapped into set space then the overloaded behavior will |
12 |
>> come from them being referenced as sets, which won't overload their |
13 |
>> ebuild behavior since they can simply behave like existing |
14 |
>> meta-packages already do. |
15 |
> |
16 |
> Ok, so say we have cat/foo-1: |
17 |
> |
18 |
> PROPERTIES="" |
19 |
> DEPEND="cat/one cat/two cat/three" |
20 |
> RDEPEND="cat/two cat/four" |
21 |
> |
22 |
> and cat/foo-2: |
23 |
> |
24 |
> PROPERTIES="set" |
25 |
> DEPEND="cat/one cat/two cat/three" |
26 |
> RDEPEND="cat/two cat/four" |
27 |
> |
28 |
> Then what does this do in package.use? |
29 |
> |
30 |
> cat/foo monkey |
31 |
> |
32 |
> What does this do in package.mask? |
33 |
> |
34 |
> cat/foo |
35 |
> |
36 |
> What about this? |
37 |
> |
38 |
> >=cat/foo-2 |
39 |
> |
40 |
> What about this? |
41 |
> |
42 |
> <cat/foo-2 |
43 |
> |
44 |
> What does this do? |
45 |
> |
46 |
> emerge -uDpv cat/foo |
47 |
> |
48 |
> What about this? |
49 |
> |
50 |
> emerge -uDpv \>=cat/foo-2 |
51 |
> |
52 |
> What about this? |
53 |
> |
54 |
> emerge -uDpv \<cat/foo-2 |
55 |
> |
56 |
> Now let's introduce cat/bar-1: |
57 |
> |
58 |
> DEPEND="cat/foo" |
59 |
> |
60 |
> and cat/bar-2: |
61 |
> |
62 |
> DEPEND="=cat/foo-1" |
63 |
> |
64 |
> What does this do? |
65 |
> |
66 |
> emerge -e cat/bar |
67 |
> |
68 |
> What about: |
69 |
> |
70 |
> emerge -e =cat/bar-1 |
71 |
> |
72 |
> And how is this anything other than highly weird? |
73 |
|
74 |
As I've tried to explain, the an ebuild which exhibits |
75 |
PROPERTIES=set doesn't necessarily have to behave any differently |
76 |
than a meta-package currently does. What we would do is create a |
77 |
configuration that maps the set-property ebuild into set space. For |
78 |
example, `emerge kde-meta` would behave as as normal meta-package |
79 |
currently does, and `emerge @kde-meta` would reference the same |
80 |
package as a set and could thereby trigger different behavior which |
81 |
is appropriate for a set. |
82 |
|
83 |
> Here's an alternate proposal: Repositories can ship sets via files in |
84 |
> sets/*.conf. The format is as described in [1]. In configuration files, |
85 |
> operations applied to a set are applied to anything matching any spec |
86 |
> listed in that set (or any set that set contains, and so on). On the |
87 |
> command line, sets and non-sets cannot be mixed, and multiple sets |
88 |
> cannot be specified. |
89 |
> |
90 |
> [1]: http://paludis.pioto.org/configuration/sets.html |
91 |
> |
92 |
|
93 |
Perhaps can use something like you've got there in addition to the |
94 |
PROPERTIES=set approach. |
95 |
|
96 |
- -- |
97 |
Thanks, |
98 |
Zac |
99 |
-----BEGIN PGP SIGNATURE----- |
100 |
Version: GnuPG v2.0.9 (GNU/Linux) |
101 |
|
102 |
iEYEARECAAYFAkjgC5oACgkQ/ejvha5XGaP0XwCdGbv7hIybD0k+GwRDTmyum3yY |
103 |
kusAoIs4Imz4tNtb18srdk3VzJM/+ZHJ |
104 |
=h5ii |
105 |
-----END PGP SIGNATURE----- |