Gentoo Archives: gentoo-dev

From: Zac Medico <zmedico@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>
Cc: gentoo-portage-dev@l.g.o
Subject: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
Date: Fri, 03 Oct 2008 07:11:21
2 Hash: SHA1
4 Hi everyone,
6 This is a revised version of the PROPERTIES=set proposal which has
7 been discussed previously [1].
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.
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.
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.
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.
54 Does this seem like a good approach? Are there any suggestions for
55 improvements or alternative approaches?
57 [1]
59 [2]
61 [3]
62 - --
63 Thanks,
64 Zac
68 Version: GnuPG v2.0.9 (GNU/Linux)
70 iEYEARECAAYFAkjlxX4ACgkQ/ejvha5XGaMv2gCggj2YCW3MkcW/Y/EQUPX+V38E
71 4DgAnR3d4mD5Y4S2qGZRbq8md1NJnLE7
72 =AdHx
73 -----END PGP SIGNATURE-----