[pacman-dev] backends

[Roman Kyrylych]

2006/10/27, Jürgen Hötzel <juergen at 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 (Роман Кирилич)