1 |
On Fri, 03 Oct 2008 00:10:56 -0700 |
2 |
Zac Medico <zmedico@g.o> wrote: |
3 |
> For the new "sets" profile configuration file format, the simplest |
4 |
> possible layout could have a set name in the first column and a |
5 |
> package atom in the second column. The package atom should match an |
6 |
> ebuild which exhibits the "set" property. In addition to the set |
7 |
> name and atom columns, we may also want to include an EAPI column |
8 |
> which the package manager can use to ensure that it parses the atom |
9 |
> syntax correctly. |
10 |
|
11 |
We probably want to start putting a profile_eapi file in each profile |
12 |
directory or something like that... Get package managers to refuse to |
13 |
use any profile that contains a directory using an eapi it doesn't |
14 |
know. This'll help sort out the slot deps in profiles issue too. |
15 |
|
16 |
> Similar to the proposed "virtual" property [2], the "set" property |
17 |
> will indicate that dependency calculations should consider the |
18 |
> ebuild to have zero installation cost. |
19 |
|
20 |
If we go this route, that needs to be a property of its own, really. |
21 |
Otherwise we'll end up with a dozen properties all of which imply |
22 |
particular different real properties. |
23 |
|
24 |
> I order to determine which atoms correspond to a given set, the |
25 |
> first step is to lookup the set name from the profile's "sets" |
26 |
> configuration files. The corresponding package atom is then resolved |
27 |
> to a specific ebuild which should exhibit the "set" property. The |
28 |
> dependency atoms from this ebuild's RDEPEND variable will serve to |
29 |
> make up the atoms of the package set. In cases when these atoms |
30 |
> resolve to other ebuilds that exhibit he "set" property then those |
31 |
> other ebuilds act as nested sets and this nesting process is |
32 |
> recursive with no limit on the depth of nesting. The nested sets do |
33 |
> not necessarily have to be mapped to specific set names by the |
34 |
> profile's "sets" configuration files. If nested sets are anonymous |
35 |
> in this sense then their atoms still become a part of the set that |
36 |
> they are nested within, just as they would if they had been given a |
37 |
> name by the profile's "sets" configuration files. |
38 |
|
39 |
Why not just invent a syntax that lets you take an arbitrary ebuild |
40 |
and use an arbitrary dep key from it as a set? Say, something like |
41 |
@RDEPEND(=foo/bar-1.23) . No need for any PROPERTIES or mapping |
42 |
mess at all... |
43 |
|
44 |
> Does this seem like a good approach? Are there any suggestions for |
45 |
> improvements or alternative approaches? |
46 |
|
47 |
This looks to me as if you're trying to find uses for PROPERTIES, |
48 |
rather than trying to find ways to solve a problem. |
49 |
|
50 |
-- |
51 |
Ciaran McCreesh |