List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
Gentoo Dev <firstname.lastname@example.org>
Zac Medico <email@example.com>
[RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
Fri, 03 Oct 2008 00:10:56 -0700
-----BEGIN PGP SIGNED MESSAGE-----
This is a revised version of the PROPERTIES=set proposal which has
been discussed previously .
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
Similar to the proposed "virtual" property , the "set" property
will indicate that dependency calculations should consider the
ebuild to have zero installation cost. Similar to glep 37 ,
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
-----END PGP SIGNATURE-----