On Mon, Mar 23, 2009 at 4:24 PM, Philipp Riegger <lists@...> wrote:
> 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?

I think "binary only profile" ?

>
> Philipp
>
>