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
