-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone,
This is a revised version of the PROPERTIES=set proposal which has been discussed previously [1]. Please consider a PROPERTIES=set value will serve to indicate that a given ebuild should be exposed within the package set framework as a package set. In order to expose such an ebuild as a package set, a new "sets" profile configuration file will serve to define mappings from set names to package atoms. Similar to the existing "virtuals" file which is already supported by profiles, the "sets" file will allow a given profile to override any mappings that have been defined by parent profiles. The bulk of the mappings will be defined in profiles/base/sets, since all profiles should inherit the same set mappings unless they need to be overridden for some reason. For the new "sets" profile configuration file format, the simplest possible layout could have a set name in the first column and a package atom in the second column. The package atom should match an ebuild which exhibits the "set" property. In addition to the set name and atom columns, we may also want to include an EAPI column which the package manager can use to ensure that it parses the atom syntax correctly. Similar to the proposed "virtual" property [2], the "set" property will indicate that dependency calculations should consider the ebuild to have zero installation cost. Similar to glep 37 [3], ebuilds that exhibit PROPERTIES=set should also define all of their dependencies in the RDEPEND variable. Other than these constraints, an ebuild which exhibits PROPERTIES=set should behave just like any other ebuild. It should be installed and uninstalled just like any other ebuild, including execution of all the normal ebuild phase functions that would be executed for any other ebuild that does not exhibit the "set" property. I order to determine which atoms correspond to a given set, the first step is to lookup the set name from the profile's "sets" configuration files. The corresponding package atom is then resolved to a specific ebuild which should exhibit the "set" property. The dependency atoms from this ebuild's RDEPEND variable will serve to make up the atoms of the package set. In cases when these atoms resolve to other ebuilds that exhibit he "set" property then those other ebuilds act as nested sets and this nesting process is recursive with no limit on the depth of nesting. The nested sets do not necessarily have to be mapped to specific set names by the profile's "sets" configuration files. If nested sets are anonymous in this sense then their atoms still become a part of the set that they are nested within, just as they would if they had been given a name by the profile's "sets" configuration files. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? [1] http://archives.gentoo.org/gentoo-dev/msg_02020c2650449920c941adf46dbf7d6f.xml [2] http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml [3] http://archives.gentoo.org/proj/en/glep/glep-0037.html - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjlxX4ACgkQ/ejvha5XGaMv2gCggj2YCW3MkcW/Y/EQUPX+V38E 4DgAnR3d4mD5Y4S2qGZRbq8md1NJnLE7 =AdHx -----END PGP SIGNATURE-----
