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