1 |
On Dec 17, 2007 12:20 PM, Bo Ørsted Andresen <bo.andresen@××××.dk> wrote: |
2 |
> On Monday 17 December 2007 14:38:30 Raphael wrote: |
3 |
> > So, even if Portage was recoded in C++, performance improvements |
4 |
> > would be marginal and the cost in man-hours would be too high. It |
5 |
> > would take months before reaching the maturity level Portage has now |
6 |
> > and all this time could be better spent trying to find solutions to |
7 |
> > its architectural bottlenecks. |
8 |
> > |
9 |
> > I believe that a good solution would be evolving Portage to use |
10 |
> > different forms of storage, like databases or even LDAP. In a home |
11 |
> > desktop, you could use SQLite, which is light weight. In a Office |
12 |
> > enviroment, you could use a larger database, like MySQL or PostgreSQL. |
13 |
> > In this second case, it would even make sharing the package list |
14 |
> > faster, since the only current method is sharing it over NFS. |
15 |
> > |
16 |
> > I understand that doing so could bloat Portage dependencies, but |
17 |
> > it is, IMHO, a good way to improve its speed. |
18 |
> |
19 |
> This post is hilarious for several reasons. Firstly there already exist a |
20 |
> package manager for Gentoo which is written in C++. Paludis. And it has a lot |
21 |
> of features that Portage has been missing for five years. And it's way more |
22 |
> flexible than Portage. Secondly if you just put ebuilds in a database you |
23 |
> gain nothing. I.e. other than the added bloat. I/O is still going to be the |
24 |
> major bottleneck. :P |
25 |
|
26 |
Hey, I made someone laugh today. Good deed of the day: check! :P |
27 |
|
28 |
I was unaware of Paludis. Re-reading the thread now, I saw that |
29 |
someone mentioned it. After googling for it, seems a lot of people are |
30 |
fond of it. Why is it not the default package manager yet? |
31 |
|
32 |
As for the second part, yes, using a database wouldn't get rid of the |
33 |
I/O problem, but could diminish it, since database data isn't spread |
34 |
across several directories and files. And I'm not proposing to store |
35 |
the entire ebuild within, but a representation of it that could be |
36 |
easily queried. |
37 |
|
38 |
> |
39 |
> -- |
40 |
> Bo Andresen |
41 |
> |
42 |
éí¢‹¬z¸žÚ(¢¸&j)bž b² |