1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Ciaran McCreesh wrote: |
5 |
> On Sat, 27 Sep 2008 17:21:18 -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 |
> |
10 |
> Strikes me as a good way of causing extreme confusion for users... |
11 |
|
12 |
Perhaps it's not so confusing if the packages continue to behave |
13 |
normally in the usual cases, but they are mapped into set space as |
14 |
suggested earlier [1]. |
15 |
|
16 |
> Consider sets in package.use, for example. Any specified flags should |
17 |
> apply to the entire set. But what about set-property packages? |
18 |
|
19 |
In order to fit into the ebuild framework, the specified flags would |
20 |
only apply to direct dependency atoms. Atoms pulled in by recursion |
21 |
into other set-property packages would have the flags applied from |
22 |
those respective set-property packages. |
23 |
|
24 |
> Sets and packages aren't the same thing, and shouldn't be treated as if |
25 |
> they are. |
26 |
|
27 |
Packages and virtuals aren't the same thing either, but glep 37 |
28 |
virtuals fit quite well into the existing ebuild framework. It seems |
29 |
to me that set-property packages will also fit nicely into the |
30 |
existing ebuild framework. |
31 |
|
32 |
[1] |
33 |
http://archives.gentoo.org/gentoo-dev/msg_d858a9a516fe3d1996c3809fba56f1db.xml |
34 |
- -- |
35 |
Thanks, |
36 |
Zac |
37 |
-----BEGIN PGP SIGNATURE----- |
38 |
Version: GnuPG v2.0.9 (GNU/Linux) |
39 |
|
40 |
iEYEARECAAYFAkjf7rcACgkQ/ejvha5XGaNlzQCfYrvTNDVTqqZjXgc7rUkfjT6J |
41 |
8PMAmgLkC4dcprNL6GnuHzWUzM9zabxk |
42 |
=91yT |
43 |
-----END PGP SIGNATURE----- |