From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NbBxs-0008R3-H5 for garchives@archives.gentoo.org; Sat, 30 Jan 2010 11:58:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03434E080C; Sat, 30 Jan 2010 11:57:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D39B3E080C for ; Sat, 30 Jan 2010 11:57:52 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 528E81B402E for ; Sat, 30 Jan 2010 11:57:52 +0000 (UTC) Message-ID: <4B641F1F.5060101@gentoo.org> Date: Sat, 30 Jan 2010 03:59:27 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091218 Thunderbird/3.0 ThunderBrowse/3.2.6.8 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Building custom package for multi-arch/system References: <20100128151741.GC4462@lady-voodoo.exosec.local> <20100129052415.GA6088@bbone> In-Reply-To: <20100129052415.GA6088@bbone> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 5edb8b17-0137-41d4-b90e-d300903b8843 X-Archives-Hash: 3ecdbd7561e21625f3a065f883f4d42d On 01/28/2010 09:24 PM, Max Arnold wrote: > On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote: >> So, do you guys plan to implement a such thing ? That's one of the >> features that is mostly missing imho. The principal miss in on client >> side as I have tools to manage packages but would like to not have too >> much specific scripts on client side. > > I like the way it done in OpenEmbedded. You have the tree of recipes (think of portage tree) > and bunch of targets. For each target BitBake can generate binary release and package feed. > Client package management is lightweight and does not require BitBake, recipes tree and even > python. At least this is my lame interpretation of how it works :) You can do something similar using the emerge --config-root option. You'd just use a different --config-root for each target, and each of those would have a separate $PKGDIR. > Maybe this "metadistribution" approach is cleaner than binary package support in emerge. If > user wants to compile packages on the client, he uses portage. If not - he can setup build > server for multiple targets and completely drop portage from client machines. The only thing > client should know is feed url with full list of binary packages. And I do not think client > should deal with USE flags - for large installations unification is the only sane way to scale. The clients need sys-apps/portage installed, but not the whole portage tree (although the profiles directory can be useful for the profile and package moves). The clients should set PORTAGE_BINHOST in make.conf, so that binary packages are automatically downloaded with the emerge -g option. -- Thanks, Zac