P2P Packaging/Koji Cloud
supergiantpotato at yahoo.co.jp
Wed Dec 7 20:35:02 UTC 2011
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.
But on the technical side...
I don't think bandwidth would be much of an issue, for one thing it
could be throttleable and with a huge number of available systems this
still results in an overabundance of available systems for build. And
anyway most Fedora users have no problem sucking down a DVD-sized spin
each time they want to try something other than the default desktop.
If this were implemented the entire cycle should be per package or
perhaps per some limit of packages that is user-configurable (like "do
blocks of 10 rpms" or "do blocks of packages > 500Mb && < 1Gb"). With
parceled building like that the iterations are smaller but more
frequent, and I think less of a burden for someone who just wants to try
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.
More information about the devel