| 1 |
Max Arnold dixit (2010-01-29, 12:24): |
| 2 |
|
| 3 |
> On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote: |
| 4 |
> > So, do you guys plan to implement a such thing ? That's one of the |
| 5 |
> > features that is mostly missing imho. The principal miss in on |
| 6 |
> > client side as I have tools to manage packages but would like to not |
| 7 |
> > have too much specific scripts on client side. |
| 8 |
> |
| 9 |
> I like the way it done in OpenEmbedded. You have the tree of recipes |
| 10 |
> (think of portage tree) and bunch of targets. For each target BitBake |
| 11 |
> can generate binary release and package feed. Client package |
| 12 |
> management is lightweight and does not require BitBake, recipes tree |
| 13 |
> and even python. At least this is my lame interpretation of how it |
| 14 |
> works :) |
| 15 |
> |
| 16 |
> Maybe this "metadistribution" approach is cleaner than binary package |
| 17 |
> support in emerge. If user wants to compile packages on the client, he |
| 18 |
> uses portage. If not - he can setup build server for multiple targets |
| 19 |
> and completely drop portage from client machines. The only thing |
| 20 |
> client should know is feed url with full list of binary packages. And |
| 21 |
> I do not think client should deal with USE flags - for large |
| 22 |
> installations unification is the only sane way to scale. |
| 23 |
|
| 24 |
I think something similar is very nicely done on R-Path based |
| 25 |
distributions (with "flavours" [1]). Conary itself also seems to be a |
| 26 |
pretty well thought out package manager. |
| 27 |
|
| 28 |
[1] http://docs.rpath.com/conary/Conaryopedia/sect-flavors.html |
| 29 |
|
| 30 |
-- |
| 31 |
[a] |
Archives