1 |
On 01/28/2010 09:24 PM, Max Arnold wrote: |
2 |
> On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote: |
3 |
>> So, do you guys plan to implement a such thing ? That's one of the |
4 |
>> features that is mostly missing imho. The principal miss in on client |
5 |
>> side as I have tools to manage packages but would like to not have too |
6 |
>> much specific scripts on client side. |
7 |
> |
8 |
> I like the way it done in OpenEmbedded. You have the tree of recipes (think of portage tree) |
9 |
> and bunch of targets. For each target BitBake can generate binary release and package feed. |
10 |
> Client package management is lightweight and does not require BitBake, recipes tree and even |
11 |
> python. At least this is my lame interpretation of how it works :) |
12 |
|
13 |
You can do something similar using the emerge --config-root option. |
14 |
You'd just use a different --config-root for each target, and each |
15 |
of those would have a separate $PKGDIR. |
16 |
|
17 |
> Maybe this "metadistribution" approach is cleaner than binary package support in emerge. If |
18 |
> user wants to compile packages on the client, he uses portage. If not - he can setup build |
19 |
> server for multiple targets and completely drop portage from client machines. The only thing |
20 |
> client should know is feed url with full list of binary packages. And I do not think client |
21 |
> should deal with USE flags - for large installations unification is the only sane way to scale. |
22 |
|
23 |
The clients need sys-apps/portage installed, but not the whole |
24 |
portage tree (although the profiles directory can be useful for |
25 |
the profile and package moves). The clients should set |
26 |
PORTAGE_BINHOST in make.conf, so that binary packages are |
27 |
automatically downloaded with the emerge -g option. |
28 |
-- |
29 |
Thanks, |
30 |
Zac |