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