From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 35F50138AED for ; Mon, 18 Feb 2013 19:13:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ADCFD21C01A; Mon, 18 Feb 2013 19:13:29 +0000 (UTC) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E759221C01A for ; Mon, 18 Feb 2013 19:13:28 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id er20so5842233lab.18 for ; Mon, 18 Feb 2013 11:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CSaVhjh9I9hftZh1zDA4SvSZTE+o04ihpi/b/2KfnPA=; b=vvWJpGoCrIZJ0Qv9y6bPiVjLIopzMAztvBDx2aOt3+LYUTmFtvvL+LJBZqVp+Do2wG H6GBokFavACJkuscpL/vhXuH5qjXq9/OwQEBvXXpXzelBaMdREOsgcnvYm2Oxkjrm/0t awzow/TqQXCNRFHHqO0cQdgcRFKqR4ciHwNmMofnoII1EqA4+OiTUa8cmM32sRHL5PIv n3uJj8R7n6S0odsVOnhNF+g3v08J9el5G7okGhWxvQV51fO8xEpK9MmobxiHWjxBX9rj h5V0XN7WBZMYPBjftdeAWSH9STO2rx/5UaJTuZgHNeStm8+8Q7PVET5aFp4lBGvFTDW+ Zj1w== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.152.132.36 with SMTP id or4mr10142238lab.8.1361214807146; Mon, 18 Feb 2013 11:13:27 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.114.2.230 with HTTP; Mon, 18 Feb 2013 11:13:26 -0800 (PST) In-Reply-To: <512234C6.8060401@gentoo.org> References: <1361194187.18852.170.camel@Coffee> <512234C6.8060401@gentoo.org> Date: Mon, 18 Feb 2013 14:13:26 -0500 X-Google-Sender-Auth: QahC-U4RS35CGgvw4Sema3i2Vco Message-ID: Subject: Re: [gentoo-soc] Project Proposal : GenCC for "Gentoo Community Compiling" From: Rich Freeman To: gentoo-soc@lists.gentoo.org Cc: Antoine Pinsard Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: b2d7b972-ff3e-4969-bcf9-eaf403e463ae X-Archives-Hash: 77609a8c40bfcbfec316685b45ea300b On Mon, Feb 18, 2013 at 9:03 AM, Patrick Lauer wrote: (note, switching order I comment in) (Note also - I'm not sold on any of this being practical - this is an outline of how the obstacles might be surmounted.) > > How do you manage to get a precise environment (including useflags, > correct gcc version, ...) onto the compile host? Wouldn't that be slower > than building it locally? So, the premise is that if you build a package with identical dependencies you'll get an identical output. That is using a definition of dependency as anything involved in the creation of the package. So, for this to work you'd need to: 1. ID all the dependencies of a package (INCLUDING system packages). We don't do this for various reasons, and that would be a problem, unless the data is somehow gathered by the tool or we change our policies. 2. ID the versions and configurations of all the dependencies. That would include USE flags at least. Hopefully nothing build-time depends on configuration files, but that might also be an issue. 3. ID hosts who have identical configurations, and use them to build. However, if you're going to do all of that stuff, you could just as easily assemble a binary packages catalog. Why distribute all the compiling when you can just ask for what should be an identical final executable? > So, how do you handle people being evil? What happens if my genccd > always returns 0-byte files? what if it adds random things to execute > code on the user's system? I'd also want to make sure that the attacks can't go the other way as well. If nothing else you're open to a CPU-using DOS (compile this 2GB file full of really complex C++ abstractions for me). For the output you could have some kind of web-of-trust where multiple people do the work and report the hash/etc. Again, a binary package repository shouldn't really be any harder to implement and makes far more sense all around. Then everybody just reports their hashes, or we could have an official list of these and mirrors/etc. Distributed CC within an organization makes more sense as it eliminates the trust issues, mostly (you might still care about reliability, but not malicious attacks). However, a single organization is also likely to have more uniform configuration, and thus a binary repository makes even more sense. I think the big question is - what does distributed compilation get us that a binary repository doesn't get us, or in what way is it easier? I can't really think of any advantages of the former over the latter. Both will still be a challenge to implement, and that might start with fully identifying dependencies. Rich