On Thu, 08 Dec 2011 05:35:02 +0900
夜神 岩男 <supergiantpotato(a)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