1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Hi everyone, |
5 |
|
6 |
This is a revised version of the PROPERTIES=set proposal which has |
7 |
been discussed previously [1]. |
8 |
|
9 |
Please consider a PROPERTIES=set value will serve to indicate that a |
10 |
given ebuild should be exposed within the package set framework as a |
11 |
package set. In order to expose such an ebuild as a package set, a |
12 |
new "sets" profile configuration file will serve to define mappings |
13 |
from set names to package atoms. Similar to the existing "virtuals" |
14 |
file which is already supported by profiles, the "sets" file will |
15 |
allow a given profile to override any mappings that have been |
16 |
defined by parent profiles. The bulk of the mappings will be defined |
17 |
in profiles/base/sets, since all profiles should inherit the same |
18 |
set mappings unless they need to be overridden for some reason. |
19 |
|
20 |
For the new "sets" profile configuration file format, the simplest |
21 |
possible layout could have a set name in the first column and a |
22 |
package atom in the second column. The package atom should match an |
23 |
ebuild which exhibits the "set" property. In addition to the set |
24 |
name and atom columns, we may also want to include an EAPI column |
25 |
which the package manager can use to ensure that it parses the atom |
26 |
syntax correctly. |
27 |
|
28 |
Similar to the proposed "virtual" property [2], the "set" property |
29 |
will indicate that dependency calculations should consider the |
30 |
ebuild to have zero installation cost. Similar to glep 37 [3], |
31 |
ebuilds that exhibit PROPERTIES=set should also define all of their |
32 |
dependencies in the RDEPEND variable. Other than these constraints, |
33 |
an ebuild which exhibits PROPERTIES=set should behave just like any |
34 |
other ebuild. It should be installed and uninstalled just like any |
35 |
other ebuild, including execution of all the normal ebuild phase |
36 |
functions that would be executed for any other ebuild that does not |
37 |
exhibit the "set" property. |
38 |
|
39 |
I order to determine which atoms correspond to a given set, the |
40 |
first step is to lookup the set name from the profile's "sets" |
41 |
configuration files. The corresponding package atom is then resolved |
42 |
to a specific ebuild which should exhibit the "set" property. The |
43 |
dependency atoms from this ebuild's RDEPEND variable will serve to |
44 |
make up the atoms of the package set. In cases when these atoms |
45 |
resolve to other ebuilds that exhibit he "set" property then those |
46 |
other ebuilds act as nested sets and this nesting process is |
47 |
recursive with no limit on the depth of nesting. The nested sets do |
48 |
not necessarily have to be mapped to specific set names by the |
49 |
profile's "sets" configuration files. If nested sets are anonymous |
50 |
in this sense then their atoms still become a part of the set that |
51 |
they are nested within, just as they would if they had been given a |
52 |
name by the profile's "sets" configuration files. |
53 |
|
54 |
Does this seem like a good approach? Are there any suggestions for |
55 |
improvements or alternative approaches? |
56 |
|
57 |
[1] |
58 |
http://archives.gentoo.org/gentoo-dev/msg_02020c2650449920c941adf46dbf7d6f.xml |
59 |
[2] |
60 |
http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml |
61 |
[3] http://archives.gentoo.org/proj/en/glep/glep-0037.html |
62 |
- -- |
63 |
Thanks, |
64 |
Zac |
65 |
|
66 |
|
67 |
-----BEGIN PGP SIGNATURE----- |
68 |
Version: GnuPG v2.0.9 (GNU/Linux) |
69 |
|
70 |
iEYEARECAAYFAkjlxX4ACgkQ/ejvha5XGaMv2gCggj2YCW3MkcW/Y/EQUPX+V38E |
71 |
4DgAnR3d4mD5Y4S2qGZRbq8md1NJnLE7 |
72 |
=AdHx |
73 |
-----END PGP SIGNATURE----- |