| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Am 29.03.2011 17:47, schrieb Zac Medico: |
| 5 |
>> 2. Using the VCS |
| 6 |
>> Store the versions of eclasses in the metadata and fetch it from a |
| 7 |
>> repository before installing the ebuilds. This would pull a dependency |
| 8 |
>> on a VCS (CVS in this case), though. |
| 9 |
> |
| 10 |
> Not necessarily. If the ebuild metadata contains UUIDs that the client |
| 11 |
> can translate to URIs using a predefined protocol, then the client |
| 12 |
> simply needs to be aware of the protocol so that it can fetch the |
| 13 |
> appropriate URIs. |
| 14 |
> |
| 15 |
|
| 16 |
Although I like the idea with the UUID, I don't know if it is really |
| 17 |
worth the trouble. Due to the number of eclasses let alone the files in |
| 18 |
/usr/portage/profile, there is a huge number of permutations and you |
| 19 |
would need a very complex (in terms of size) UUID. |
| 20 |
|
| 21 |
Is it enough for an SoC project to "just" make portage leave out the |
| 22 |
ebuilds on synchronization? |
| 23 |
This would be of similar scope as the original idea (Cache sync). |
| 24 |
|
| 25 |
I also miss the documentation a bit, to be honest. Maybe improving the |
| 26 |
portage documentation would be a nice addition? |
| 27 |
-----BEGIN PGP SIGNATURE----- |
| 28 |
Version: GnuPG v2.0.17 (GNU/Linux) |
| 29 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
| 30 |
|
| 31 |
iEYEARECAAYFAk2TaX8ACgkQnzX+Jf4GTUxsdgCfRXDz4MGSBkz7iVugjMjSwNr1 |
| 32 |
/loAn2i07Y0tVLgfvGWHipiFW+RVa5JP |
| 33 |
=Frv4 |
| 34 |
-----END PGP SIGNATURE----- |
Archives