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