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