| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Am 27.03.2011 21:39, schrieb Zac Medico: |
| 5 |
> On 03/27/2011 07:28 AM, Michael Seifert wrote: |
| 6 |
> I like the BINHOST metadata better, even if it is split up into several |
| 7 |
> files, because it would already contain the ebuild version it was |
| 8 |
> generated for. Probably it would be a good idea to merge the information |
| 9 |
> of both metadata into a single unified format? |
| 10 |
> This would also solve the problem with the missing version control |
| 11 |
> (described below) as well as simplifying the way portage handles |
| 12 |
> metadata. On the other hand it would be an even more substantial change, |
| 13 |
> which is not necessarily a bad thing. Portage is supposed to work the |
| 14 |
> same way as before just faster. |
| 15 |
> |
| 16 |
>> Well, a new cache format is only part of the solution. In order to |
| 17 |
>> provide revision control that's necessary for practical dependency |
| 18 |
>> calculations when the cache is fetched earlier that the |
| 19 |
>> ebuilds/eclasses, you're also going to need to create individually |
| 20 |
>> fetchable revisioned ebuild/eclass bundles that the cache will refer to |
| 21 |
>> (without any race conditions). |
| 22 |
|
| 23 |
If I understood your point correctly, there can be problems, if there |
| 24 |
are changes to eclasses after a user ran emerge --sync and before the |
| 25 |
ebuilds are fetched (race condition between server and client). In such |
| 26 |
a case, the correct ebuild would be installed using a wrong environment |
| 27 |
(i.e. the wrong eclasses), because the metadata is outdated and contains |
| 28 |
wrong dependencies. Did this cover your outlined case? |
| 29 |
|
| 30 |
I can think of three solutions for this: |
| 31 |
1. Self-contained ebuilds |
| 32 |
Your proposal of packaging the ebuild together with its eclasses and the |
| 33 |
source code would make the need of eclass versioning unnecessary, since |
| 34 |
the ebuild is always packaged within the correct environment. |
| 35 |
(Creates a new race condition, see your link :) |
| 36 |
|
| 37 |
2. Using the VCS |
| 38 |
Store the versions of eclasses in the metadata and fetch it from a |
| 39 |
repository before installing the ebuilds. This would pull a dependency |
| 40 |
on a VCS (CVS in this case), though. |
| 41 |
|
| 42 |
3. Fetching the eclasses together with the metadata |
| 43 |
This way you would have a local snapshot of the build environment, which |
| 44 |
would eliminate the race condition and the need to identify eclass |
| 45 |
versions from the metadata, because it stays consitent. |
| 46 |
-----BEGIN PGP SIGNATURE----- |
| 47 |
Version: GnuPG v2.0.17 (GNU/Linux) |
| 48 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
| 49 |
|
| 50 |
iEYEARECAAYFAk2R7V0ACgkQnzX+Jf4GTUyUWwCfXhrDkUotVqvaef81Mj27bWF1 |
| 51 |
WqkAoM4a3WcnkQVBIhtOvnGFjzr3OL5m |
| 52 |
=cUbO |
| 53 |
-----END PGP SIGNATURE----- |
Archives