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