P2P Packaging/Koji Cloud

seth vidal skvidal at fedoraproject.org
Wed Dec 7 21:12:11 UTC 2011


On Thu, 08 Dec 2011 05:35:02 +0900
夜神 岩男 <supergiantpotato at yahoo.co.jp> wrote:

> On 12/08/2011 05:12 AM, seth vidal wrote:
> > Bandwidth is the big concern for the end user here and then the
> > other issue is  - is all of this worth it for building pkgs? I
> > don't think it is, personally, pkg building is not that huge of a
> > hit, afaict to getting things done.
> >
> > I mean the sum total of the steps were talking about, even now is
> > more or less:
> >
> > 1. init host
> > 2. stuff some files onto it
> > 3. start up a process
> > 4. communicate to that process
> > 5. build pkg
> > 6. stuff pkgs into a local repo
> > 7. go to 5 until no more pkgs
> > 8. download all pkgs back to original client
> > 9. destroy host.
> >
> > you can do it now if you're willing to do steps 5-8 manually.
> 
> I think you are correct in essentially asking if this is a solution
> in search of a problem.
> 
> 
> And on the practical side...
> This all goes back to the first sentence in this response. While it
> is very possible to do something like this, and the idea is exciting 
> because it is something new, I've never heard of anyone kicking and 
> screaming about a wait que bottleneck or insufficient resources in
> the Fedora infrastructure. I've also not heard anything like "RH is
> going to drop Fedora so we need to look for a new home", either. I
> was simply addressing the "how to make it secure" element. This is a
> workable method which relies 100% on volunteers (i.e. community
> resource use, not a paid solution) VS going to some overwrought cloud
> solution for which there really isn't any backstop for integrity
> checking compared to the distributed build crosscheck I've described
> above.


So - there is no shortage of resources for building stuff. There is no
threat of anyone dropping anything. There is however the following:

 We want to be able to build pkgs from people we do not trust and using
 sources of BuildRequirements we do not trust. We cannot do that on our
 existing infrastructure b/c it is FAR too trivial for a malicious
 buildrequirement to walk its way out of a chroot.

that's the driving force.
-sv


More information about the devel mailing list