On Fri, 03 Oct 2008 00:10:56 -0700
Zac Medico <zmedico@g.o> wrote:
> 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.

We probably want to start putting a profile_eapi file in each profile
directory or something like that... Get package managers to refuse to
use any profile that contains a directory using an eapi it doesn't
know. This'll help sort out the slot deps in profiles issue too.

> Similar to the proposed "virtual" property [2], the "set" property
> will indicate that dependency calculations should consider the
> ebuild to have zero installation cost.

If we go this route, that needs to be a property of its own, really.
Otherwise we'll end up with a dozen properties all of which imply
particular different real properties.

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

Why not just invent a syntax that lets you take an arbitrary ebuild
and use an arbitrary dep key from it as a set? Say, something like
@RDEPEND(=foo/bar-1.23) . No need for any PROPERTIES or mapping
mess at all...

> Does this seem like a good approach? Are there any suggestions for
> improvements or alternative approaches?

This looks to me as if you're trying to find uses for PROPERTIES,
rather than trying to find ways to solve a problem.

-- 
Ciaran McCreesh