| 1 |
On 01/13/14 04:31 PM, Fabio Erculiani wrote: |
| 2 |
> On Mon, Jan 13, 2014 at 10:15 AM, "C. Bergström" |
| 3 |
> <cbergstrom@×××××××××.com> wrote: |
| 4 |
>> On 01/13/14 03:43 PM, Alexander Berntsen wrote: |
| 5 |
>> Where I work uses pkgcore[1], but not the areas which are generally |
| 6 |
>> beneficial to the whole community. (We use it as part of a web application |
| 7 |
>> to handle testsuites which have build dependencies.) We can blah blah about |
| 8 |
>> performance of resolving package dependencies all day long, |
| 9 |
>> [...] |
| 10 |
> Not sure about what you mean with "blah blah". But given the amount of |
| 11 |
> both disk caches (metadata, vdb cache) and memory caches (the |
| 12 |
> in-memory aux_db cache that portage loads using pickle (it's a dict) |
| 13 |
> takes like 70-100Mb of RAM on an average desktop system), Portage can |
| 14 |
> still take *minutes* to calculate the merge queue of a pkg with all |
| 15 |
> its deps satisfied. Ironically, launching the same emerge command |
| 16 |
> twice, will take more or less the same time. |
| 17 |
> Yeah, this is probably bad design... |
| 18 |
ack - I know the benefits (and downsides) of pkgcore compared to |
| 19 |
portage, but I leave that up to others who would like to voice their |
| 20 |
opinion. It would be great to get pkgcore up to feature parity with |
| 21 |
portage, but I don't have the resources to help with that. (In the |
| 22 |
future, possibly next month, I will try to put some bounties) |
Archives