1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Ciaran McCreesh wrote: |
5 |
> On Fri, 03 Oct 2008 00:10:56 -0700 |
6 |
> Zac Medico <zmedico@g.o> wrote: |
7 |
>> For the new "sets" profile configuration file format, the simplest |
8 |
>> possible layout could have a set name in the first column and a |
9 |
>> package atom in the second column. The package atom should match an |
10 |
>> ebuild which exhibits the "set" property. In addition to the set |
11 |
>> name and atom columns, we may also want to include an EAPI column |
12 |
>> which the package manager can use to ensure that it parses the atom |
13 |
>> syntax correctly. |
14 |
> |
15 |
> We probably want to start putting a profile_eapi file in each profile |
16 |
> directory or something like that... Get package managers to refuse to |
17 |
> use any profile that contains a directory using an eapi it doesn't |
18 |
> know. This'll help sort out the slot deps in profiles issue too. |
19 |
|
20 |
That's a good idea. If we do that then we can assume that all atoms |
21 |
in the profile conform to the specified EAPI. |
22 |
|
23 |
>> Similar to the proposed "virtual" property [2], the "set" property |
24 |
>> will indicate that dependency calculations should consider the |
25 |
>> ebuild to have zero installation cost. |
26 |
> |
27 |
> If we go this route, that needs to be a property of its own, really. |
28 |
> Otherwise we'll end up with a dozen properties all of which imply |
29 |
> particular different real properties. |
30 |
|
31 |
Perhaps, but there's a trade-off in having to specify two properties |
32 |
when a single property can have compound meaning. For example, |
33 |
Donnie (dberkholz) has previously expressed some concern about |
34 |
PROPERTIES being more fine-grained than they need to be [1]. |
35 |
|
36 |
>> I order to determine which atoms correspond to a given set, the |
37 |
>> first step is to lookup the set name from the profile's "sets" |
38 |
>> configuration files. The corresponding package atom is then resolved |
39 |
>> to a specific ebuild which should exhibit the "set" property. The |
40 |
>> dependency atoms from this ebuild's RDEPEND variable will serve to |
41 |
>> make up the atoms of the package set. In cases when these atoms |
42 |
>> resolve to other ebuilds that exhibit he "set" property then those |
43 |
>> other ebuilds act as nested sets and this nesting process is |
44 |
>> recursive with no limit on the depth of nesting. The nested sets do |
45 |
>> not necessarily have to be mapped to specific set names by the |
46 |
>> profile's "sets" configuration files. If nested sets are anonymous |
47 |
>> in this sense then their atoms still become a part of the set that |
48 |
>> they are nested within, just as they would if they had been given a |
49 |
>> name by the profile's "sets" configuration files. |
50 |
> |
51 |
> Why not just invent a syntax that lets you take an arbitrary ebuild |
52 |
> and use an arbitrary dep key from it as a set? Say, something like |
53 |
> @RDEPEND(=foo/bar-1.23) . No need for any PROPERTIES or mapping |
54 |
> mess at all... |
55 |
|
56 |
Well, that wouldn't allow for nesting. The idea behind the |
57 |
PROPERTIES=set approach is to integrate meta-ebuilds into the sets |
58 |
framework in a way maximizes reuse of the advantages that |
59 |
meta-ebuilds have to offer [2]. |
60 |
|
61 |
>> Does this seem like a good approach? Are there any suggestions for |
62 |
>> improvements or alternative approaches? |
63 |
> |
64 |
> This looks to me as if you're trying to find uses for PROPERTIES, |
65 |
> rather than trying to find ways to solve a problem. |
66 |
|
67 |
No, I'm trying to integrate meta-ebuilds into the sets framework and |
68 |
it just happens the PROPERTIES metadata offers a convenient way to |
69 |
separate meta-ebuilds from normal ebuilds. |
70 |
|
71 |
[1] |
72 |
http://archives.gentoo.org/gentoo-dev/msg_10a7e736c3bd2dea4223f599a463994e.xml |
73 |
[2] |
74 |
http://archives.gentoo.org/gentoo-dev/msg_f0c6b1f3a047fc83ef237e0304af6697.xml |
75 |
- -- |
76 |
Thanks, |
77 |
Zac |
78 |
-----BEGIN PGP SIGNATURE----- |
79 |
Version: GnuPG v2.0.9 (GNU/Linux) |
80 |
|
81 |
iEYEARECAAYFAkjmQBAACgkQ/ejvha5XGaP4sgCdEWuCSpUZKTwxKxOxZOTEIn3R |
82 |
bgkAnROJHVeYYG5K7rorJloHjvjNUkAe |
83 |
=fZP5 |
84 |
-----END PGP SIGNATURE----- |