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

Xavier shiningxc at gmail.com
Wed Aug 22 08:45:05 EDT 2007

On Wed, Aug 22, 2007 at 12:10:20AM -0400, Dan McGee wrote:
> 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.

Yes, I see three important points where a rewrite would help :

1) More adapted and efficient structures

A better list implentation looks indeed interesting, same for using hash
tables where it's adapted.
But what about trees / graphs ?

2) Transaction model

You had some ideas about reworking transactions :
And Nagy as well :

It's probably important to take into consideration from the beginning
that a basic install operation might induce a removal because of a conflict.
Because in the current codebase, it looks like the removal operation was
hacked on top of the code.
Same for the upgrade operation. It's basically a remove + install, but the
remove is a special one. For example, the files in backup array have to stay
in place, instead of being removed, or move to .pacsave .

3) Files extraction

maybe using suffix like dpkg does :

Being able to cleanly rollback when an error comes up would be pretty neat.
Maybe this could also helps limiting the number of times the archive is read:

Anyway, I also think pacman would benefit from a rewrite, but for it to be
really helpful, a deep understanding of the code and its current flaws is
needed. And I think I would need 10 years for getting to this point..
But you are probably able to do a nice cleanup :)

More information about the pacman-dev mailing list