| 1 |
> I'd suggest a modular approach, so that portage can support different |
| 2 |
> backends (and frontends) easier. Those who want a minimal systen can |
| 3 |
> continue to use the filesystem while people who look for more |
| 4 |
> performance can use a database server. That would require a lot of work |
| 5 |
> on portage though, probably more than carpaski alone can handle. If |
| 6 |
> there is interest on the dev side I'd be more than willing to help with |
| 7 |
> this (although my python skills are lacking, I'm more a Java and C |
| 8 |
> programmer, but I'm learning fast ;-). |
| 9 |
> |
| 10 |
> BTW, I also noted the slowness of the search function, especially when |
| 11 |
> searching in descriptions, my worst measured result was 25 minutes! Most |
| 12 |
> likely caused by a serious lack of ram, but half an hour just to find a |
| 13 |
> package is really annoying. |
| 14 |
> |
| 15 |
> Marius |
| 16 |
|
| 17 |
It would be great to have some kind of 'portage server' that could serve not only search requests etc, but also src tarballs for the packages and even compiled packages (that could be served if the USE settings they were compiled with were the same as the USE flags and architecture the client was about to compile with). That way, each LAN could have its gentoo server other boxes would just query. That server could act as a cache between public mirrors (rsync and ftp mirrors) and clients, thus reducing external bandwidth usage. |
| 18 |
|
| 19 |
That would make gentoo better for big lans with many Gentoo boxes, and maybe it could be a starting point towards having public servers to offer some compiled packages. I know many people don't like the idea, but I would love to have the option of using those compiled packages for at least big apps, eg kde. |
| 20 |
|
| 21 |
Josep Sanjuas |
| 22 |
|
| 23 |
-- |
| 24 |
gentoo-dev@g.o mailing list |
Archives