On Mon, 23 Mar 2009 08:52:38 +0200
mmacleod@... wrote:

> A p2p network of willing Gentoo users could be created where packages
> compiled by people are shared, users could select to participate in
> various different forms(or combinations of these forms) by default
> only (1) would be used: 1/ Use packages from p2p network only.
> 2/ Donate packages created by us and not already on network to
> network. Or Hash signatures in cases where package is already on
> network. 3/ Donate bandwidth/harddrive space and act as a "mirror" on
> the network, packages would be distributed between mirrors so that
> maximum redundancy exists on all packages.
> 4/ Donate idle CPU time to act as a compile server, and compile
> packages combinations that are not yet on the network. Using an
> algorithm to cover more frequent cflag combinations first.

> There obviously might be security concerns for users of such a
> system, this can be mitigated by using a central controlling server
> and by taking Hash signatures of compiled packages from users other
> then the original contributer. Different levels of trust can then be
> established for each package based on how many cross verifications of
> the Hash signature have been made. Users can then choose a level of
> trust and only use packages that meet this requirement.
> Users who still consider this to large a risk can simply not enable
> the p2p binary support at all and continue to compile everything
> obviously.

I'm not sure, if this is the right way to go. I'd prefer some kind of
build server with better configuration and management than exists at
the moment. I'm not sure, if the p2p network is trustworthy enough,
even with your hash stuff. What if a user creates a package with some
backdoor in it? How would you notice that?
 
> A fairly large part of this idea is reliant on improving portages
> binary package support as stated in the idea on the wiki. Storing
> packages based on build state and use flags etc.. so all of this
> would also be done as part of the project. Therefore my proposal is
> basically to implement everything in the "improved binary package
> support" idea(Except the kernel part) and then to implement the rest
> of the system after that.

Not sure, if this was already discussed: Usually, software has
versions. Gentoo adds revisions (these -rX endings) to have different
ebuild versions for the same software version. Now, for binary packages
we would need another revision-like addition (because there can be
pkg-foo-1.2.3 linked against lib-bar:1 and linked against lib-bar:2).
If I were the buildserver, I would build the new libbar once it is in
the tree and then use revdep-rebuild and emerge @preserved-rebuild to
figure out, what needs to be rebuilt. Then I would rebuild those
packages and increase the, let's call it binary-revision. I'd repeat
that until all was fine (which should be the case after 1 iteration,
most of the time).

Then, if you upgrade a binary host, you would upgrade all packages with
greater version or binary revision to get the binary built against the
new lib.

Another thing: Smaller installations. Maybe you could work on moving
more software out of @system, that for example gcc does not need to be
installed on binary-only hosts. Maybe you could create some
INSTALL_MASK files that would make the system smaller leaving out
headers, maybe static libraries and stuff like that. What would you
think about that one?

Philipp