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