1 |
On 03/29/2011 07:31 AM, Michael Seifert wrote: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> Am 27.03.2011 21:39, schrieb Zac Medico: |
6 |
>> On 03/27/2011 07:28 AM, Michael Seifert wrote: |
7 |
>> I like the BINHOST metadata better, even if it is split up into several |
8 |
>> files, because it would already contain the ebuild version it was |
9 |
>> generated for. Probably it would be a good idea to merge the information |
10 |
>> of both metadata into a single unified format? |
11 |
>> This would also solve the problem with the missing version control |
12 |
>> (described below) as well as simplifying the way portage handles |
13 |
>> metadata. On the other hand it would be an even more substantial change, |
14 |
>> which is not necessarily a bad thing. Portage is supposed to work the |
15 |
>> same way as before just faster. |
16 |
>> |
17 |
>>> Well, a new cache format is only part of the solution. In order to |
18 |
>>> provide revision control that's necessary for practical dependency |
19 |
>>> calculations when the cache is fetched earlier that the |
20 |
>>> ebuilds/eclasses, you're also going to need to create individually |
21 |
>>> fetchable revisioned ebuild/eclass bundles that the cache will refer to |
22 |
>>> (without any race conditions). |
23 |
> |
24 |
> If I understood your point correctly, there can be problems, if there |
25 |
> are changes to eclasses after a user ran emerge --sync and before the |
26 |
> ebuilds are fetched (race condition between server and client). In such |
27 |
> a case, the correct ebuild would be installed using a wrong environment |
28 |
> (i.e. the wrong eclasses), because the metadata is outdated and contains |
29 |
> wrong dependencies. Did this cover your outlined case? |
30 |
|
31 |
That's mostly correct, however, it's not just the eclasses that |
32 |
introduce the race condition. Just like the eclasses, the ebuilds |
33 |
themselves can be modified. In addition, so the can the files that may |
34 |
be included with the ebuilds in the "files" subdirectory ($FILESDIR). |
35 |
|
36 |
In order to be exhaustively complete, you'd also have to include any |
37 |
licenses referenced by LICENSE variable if the ebuild (these are located |
38 |
in the licenses/ subdirectory of the repository). |
39 |
|
40 |
You'd probably also want to include any matching package.mask entries |
41 |
from the global profiles/package.mask file, since this is can be very |
42 |
relevant to dependency calculations. |
43 |
|
44 |
Finally, there's the user's architecture-specific profile. This can also |
45 |
affect dependency calculations via things like package.mask, |
46 |
package.unmask, use.mask, and use.force. If you want to be entirely |
47 |
exhaustive, then you'll need your ebuild metadata to reference a |
48 |
snapshot of this profile. |
49 |
|
50 |
> I can think of three solutions for this: |
51 |
> 1. Self-contained ebuilds |
52 |
> Your proposal of packaging the ebuild together with its eclasses and the |
53 |
> source code would make the need of eclass versioning unnecessary, since |
54 |
> the ebuild is always packaged within the correct environment. |
55 |
> (Creates a new race condition, see your link :) |
56 |
|
57 |
Really, the eclass versioning would not be unnecessary, but it would be |
58 |
tied directly to the ebuild versioning. If we're going to be completely |
59 |
exhaustive, then it might make sense to have the ebuild metadata |
60 |
reference separate eclass, license, package.mask, and profile bundles. |
61 |
|
62 |
> 2. Using the VCS |
63 |
> Store the versions of eclasses in the metadata and fetch it from a |
64 |
> repository before installing the ebuilds. This would pull a dependency |
65 |
> on a VCS (CVS in this case), though. |
66 |
|
67 |
Not necessarily. If the ebuild metadata contains UUIDs that the client |
68 |
can translate to URIs using a predefined protocol, then the client |
69 |
simply needs to be aware of the protocol so that it can fetch the |
70 |
appropriate URIs. |
71 |
|
72 |
> 3. Fetching the eclasses together with the metadata |
73 |
> This way you would have a local snapshot of the build environment, which |
74 |
> would eliminate the race condition and the need to identify eclass |
75 |
> versions from the metadata, because it stays consitent. |
76 |
|
77 |
Right. But if you decide to split out license, package.mask, and profile |
78 |
bundles as discussed above, you might also decide to do that for |
79 |
eclasses as well. |
80 |
-- |
81 |
Thanks, |
82 |
Zac |