-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > 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.
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-----
