| 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----- |
Archives