[pacman-dev] Future pacman development (3.2/4.0)

[Dan McGee]

Here is a little email to get ideas flowing on what will follow the
3.1 release in pacman development.

I might as well start it off with a bang by saying I think pacman (and
especially libalpm) would be best if it got a full cleansing and
rewrite. This is one of those things that is just tough to do, but I
think all of us can see the benefits in doing it. We've seen where our
current interface is a bit lacking, and we could find many ways to
improve on that. There would also be the ability to rewrite pacman to
be much more efficient in some of the operations that are currently
the bottlenecks (namely lists).

Lists could be replaced by hash tables in a few places (package
caches?), and in other places we could simply use better list
structures in order to navigate them more efficiently. I really like
the idea of using a kernel list implementation to do this, as it would
enforce typing. However, the details of that may need to be reasonably
well hidden inside the library.

If we were to do a rewrite, I think the best way would be to do it
slowly and one piece at a time. Start with the backend interface and
slowly build from there, setting interfaces at each level. Much of the
code could be gleaned from the existing codebase, but scrutinized a
bit to ensure it is of good quality and doing things the way we want
to. Other code would end up in some burning inferno somewhere never to
be seen again, which would make me more than happy.

If we don't do a full rewrite, something that really needs looking at
is the list data structures we use. alpm_list_last (called by
alpm_list_add) is a huge bottleneck, consuming 40% of the time in a
pacman -Su operation from start to when you are presented with the
package list to install. That is pretty pathetic. A pacman -Qo
operation is another great example of the inefficiency of the existing
list structure.

Thoughts and comments welcome.

-Dan