1 |
On Mon, Mar 23, 2009 at 4:24 PM, Philipp Riegger <lists@××××××××××××.de> wrote: |
2 |
> On Mon, 23 Mar 2009 08:52:38 +0200 |
3 |
> mmacleod@××××××××××.za wrote: |
4 |
> |
5 |
>> A p2p network of willing Gentoo users could be created where packages |
6 |
>> compiled by people are shared, users could select to participate in |
7 |
>> various different forms(or combinations of these forms) by default |
8 |
>> only (1) would be used: 1/ Use packages from p2p network only. |
9 |
>> 2/ Donate packages created by us and not already on network to |
10 |
>> network. Or Hash signatures in cases where package is already on |
11 |
>> network. 3/ Donate bandwidth/harddrive space and act as a "mirror" on |
12 |
>> the network, packages would be distributed between mirrors so that |
13 |
>> maximum redundancy exists on all packages. |
14 |
>> 4/ Donate idle CPU time to act as a compile server, and compile |
15 |
>> packages combinations that are not yet on the network. Using an |
16 |
>> algorithm to cover more frequent cflag combinations first. |
17 |
> |
18 |
>> There obviously might be security concerns for users of such a |
19 |
>> system, this can be mitigated by using a central controlling server |
20 |
>> and by taking Hash signatures of compiled packages from users other |
21 |
>> then the original contributer. Different levels of trust can then be |
22 |
>> established for each package based on how many cross verifications of |
23 |
>> the Hash signature have been made. Users can then choose a level of |
24 |
>> trust and only use packages that meet this requirement. |
25 |
>> Users who still consider this to large a risk can simply not enable |
26 |
>> the p2p binary support at all and continue to compile everything |
27 |
>> obviously. |
28 |
> |
29 |
> I'm not sure, if this is the right way to go. I'd prefer some kind of |
30 |
> build server with better configuration and management than exists at |
31 |
> the moment. I'm not sure, if the p2p network is trustworthy enough, |
32 |
> even with your hash stuff. What if a user creates a package with some |
33 |
> backdoor in it? How would you notice that? |
34 |
> |
35 |
>> A fairly large part of this idea is reliant on improving portages |
36 |
>> binary package support as stated in the idea on the wiki. Storing |
37 |
>> packages based on build state and use flags etc.. so all of this |
38 |
>> would also be done as part of the project. Therefore my proposal is |
39 |
>> basically to implement everything in the "improved binary package |
40 |
>> support" idea(Except the kernel part) and then to implement the rest |
41 |
>> of the system after that. |
42 |
> |
43 |
> Not sure, if this was already discussed: Usually, software has |
44 |
> versions. Gentoo adds revisions (these -rX endings) to have different |
45 |
> ebuild versions for the same software version. Now, for binary packages |
46 |
> we would need another revision-like addition (because there can be |
47 |
> pkg-foo-1.2.3 linked against lib-bar:1 and linked against lib-bar:2). |
48 |
> If I were the buildserver, I would build the new libbar once it is in |
49 |
> the tree and then use revdep-rebuild and emerge @preserved-rebuild to |
50 |
> figure out, what needs to be rebuilt. Then I would rebuild those |
51 |
> packages and increase the, let's call it binary-revision. I'd repeat |
52 |
> that until all was fine (which should be the case after 1 iteration, |
53 |
> most of the time). |
54 |
> |
55 |
> Then, if you upgrade a binary host, you would upgrade all packages with |
56 |
> greater version or binary revision to get the binary built against the |
57 |
> new lib. |
58 |
> |
59 |
> Another thing: Smaller installations. Maybe you could work on moving |
60 |
> more software out of @system, that for example gcc does not need to be |
61 |
> installed on binary-only hosts. Maybe you could create some |
62 |
> INSTALL_MASK files that would make the system smaller leaving out |
63 |
> headers, maybe static libraries and stuff like that. What would you |
64 |
> think about that one? |
65 |
|
66 |
I think "binary only profile" ? |
67 |
|
68 |
> |
69 |
> Philipp |
70 |
> |
71 |
> |