On Fri, 03 Oct 2008 00:10:56 -0700 Zac Medico <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
