-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> 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.

That's a good idea. If we do that then we can assume that all atoms
in the profile conform to the specified EAPI.

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

Perhaps, but there's a trade-off in having to specify two properties
when a single property can have compound meaning. For example,
Donnie (dberkholz) has previously expressed some concern about
PROPERTIES being more fine-grained than they need to be [1].

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

Well, that wouldn't allow for nesting. The idea behind the
PROPERTIES=set approach is to integrate meta-ebuilds into the sets
framework in a way maximizes reuse of the advantages that
meta-ebuilds have to offer [2].

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

No, I'm trying to integrate meta-ebuilds into the sets framework and
it just happens the PROPERTIES metadata offers a convenient way to
separate meta-ebuilds from normal ebuilds.

[1]
http://archives.gentoo.org/gentoo-dev/msg_10a7e736c3bd2dea4223f599a463994e.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_f0c6b1f3a047fc83ef237e0304af6697.xml
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjmQBAACgkQ/ejvha5XGaP4sgCdEWuCSpUZKTwxKxOxZOTEIn3R
bgkAnROJHVeYYG5K7rorJloHjvjNUkAe
=fZP5
-----END PGP SIGNATURE-----