1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Am 30.03.2011 20:11, schrieb Zac Medico: |
5 |
> On 03/30/2011 10:33 AM, Michael Seifert wrote: |
6 |
> Am 29.03.2011 17:47, schrieb Zac Medico: |
7 |
>>>>> 2. Using the VCS |
8 |
>>>>> Store the versions of eclasses in the metadata and fetch it from a |
9 |
>>>>> repository before installing the ebuilds. This would pull a dependency |
10 |
>>>>> on a VCS (CVS in this case), though. |
11 |
>>>> |
12 |
>>>> Not necessarily. If the ebuild metadata contains UUIDs that the client |
13 |
>>>> can translate to URIs using a predefined protocol, then the client |
14 |
>>>> simply needs to be aware of the protocol so that it can fetch the |
15 |
>>>> appropriate URIs. |
16 |
>>>> |
17 |
> |
18 |
> Although I like the idea with the UUID, I don't know if it is really |
19 |
> worth the trouble. Due to the number of eclasses let alone the files in |
20 |
> /usr/portage/profile, there is a huge number of permutations and you |
21 |
> would need a very complex (in terms of size) UUID. |
22 |
> |
23 |
>> For our purposes, it's really not necessary to use full RFC 4122 128-bit |
24 |
>> UUIDs. For example, if the repository is only refreshed once every 30 |
25 |
>> minutes (like the rsync tree currently is), then timestamps with 1 |
26 |
>> minute precision would be more than adequate to uniquely identify a |
27 |
>> given revision of a particular bundle. |
28 |
> |
29 |
> Is it enough for an SoC project to "just" make portage leave out the |
30 |
> ebuilds on synchronization? |
31 |
> This would be of similar scope as the original idea (Cache sync). |
32 |
> |
33 |
>> The metadata/cache/ and profiles/ subdirectories would be enough |
34 |
>> information to do correct dependency calculations, but in practice I |
35 |
>> think the race conditions involved in trying to actually build anything |
36 |
>> from those calculations would lead to overwhelming dissatisfaction and |
37 |
>> complaints from users. |
38 |
> |
39 |
|
40 |
Now I got it! I was thinking much too complicated with the UUIDs. Thank |
41 |
you for the clarification! |
42 |
-----BEGIN PGP SIGNATURE----- |
43 |
Version: GnuPG v2.0.17 (GNU/Linux) |
44 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
45 |
|
46 |
iEYEARECAAYFAk2Ua6QACgkQnzX+Jf4GTUynmACgqmBA3ZLBI2hQhtGRRWkBt8tl |
47 |
icAAoJerNgjOkLB2zRGullnOSEnTwjOY |
48 |
=YmHm |
49 |
-----END PGP SIGNATURE----- |