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 ? http://www.archlinux.org/pipermail/pacman-dev/2007-June/008519.html 2) Transaction model You had some ideas about reworking transactions : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008544.html And Nagy as well : http://www.archlinux.org/pipermail/pacman-dev/2007-August/009082.html 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 : http://www.archlinux.org/pipermail/pacman-dev/2007-August/009139.html 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: http://www.archlinux.org/pipermail/pacman-dev/2007-July/008751.html 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 :)