2006/10/27, Jürgen Hötzel <juergen@hoetzel.info>:
Yes, the main problem with files backend is that huge amount of files in /var/lib/pacman that leads to slow performance on many filesystems. gdbm/sqlite/whatever has a big "+" that everithing can be in one file.
This is a big "-", because unix lovers prefer multiple text files. This makes it easy to use powerful text/file-processing tools like "sed", "awk", "shell" and "find" to build package-management related scripts.
There're nothing that don't allow to create some "API" of shell functions for doing most common operations that can be used by other shell scripts. And this way will be more backward compatible in case there will be some changes to storage format.
Plus, as I said, with SQLite you have the ability to easily use in-memory database + you have easy ACID transactions support. This will be faster than seeking through the /var/lib/pacman/ anyway. And there will be no need for pacman-optimize-like scripts for database backends. The overhead is not big. (A quote from sqlite.org: "Small code footprint: less than 250KiB fully configured or less than 150KiB with optional features omitted")
You will gain little performance (some seconds on a slow system?) at the expense of complexity.
Why not make a benchmark? ;-) Really, there are some users that complain about pacman slowness, and it's not about really slow operations like -Ss, but about really trivial operations, that shouldn't be so slow. That's because files backend is highly dependent on the type of underlying filesystem. Database backend may make these users happy,because it's not dependent on filesystem type. Personally, I don't think there's a problem _at_all_! Anyway files backend will be default in pacman3, and anyway I doubt it will be replaced soon (if ever). Why not just have an _alternative_? Keep in mind that ALPM can and will be used by other distros. Except Arch Linux and Frugalware there're Underground Linux (mostly Arch Linux Install CD + KDE and other desktop software) and Rubix Linux (formally, simply Rubix, anyway it's dead now), but I'm sure there will be some more in future (though I don't think more than 300 distros is good, even DistroWatch author thinks the same). Other distros may choose another backend. Of course, they can implement them by themselves, but anyway there was a reason why multiple backend fearure was included into ALPM. So why not to use it? Especially when it does not impose anything. Having alternatives is good, IMHO. -- Roman Kyrylych (Роман Кирилич)