[pacman-dev] [PATCH] small fix in bindings directory
aaronmgriffin at gmail.com
Thu Oct 26 15:30:36 EDT 2006
On 10/26/06, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> [offtopic on]
> BTW, about complex patches - I have a patch from Martin Devera that
> adds support for gdbm database backend to pacman 2.9.8. I suggested
> him to contact VMiklos for help in inclusion it in pacman, but I don't
> know if he did that. If I adapt it for Pacman 3 API is there a chance
> it will be included at least in CVS/DARCS?
> [/offtopic off]
There's no chance that would get included in pacman 2.9.8 - it will die soon.
Converting it to pacman3 is entirely doable and it's already setup to
do so. You should be able to copy be_files.c to be_gdbm.c and consume
the interface provided there.
FTR 'be_' means 'backend'. I still need to add compile-time flags for
selecting a backend, but as we only provide _files at the moment,
there's no need.
I worked on a 'compressed' backend that required no changes, but read
directly from the downloaded db files... it caused problems on the
local db, however, so I never completed it (yet).
As for backend schemes, I think we need to discuss avenues of attack
here. The files backend is painfully slow on ext filesystems (11
seconds to parse [community]). There are many users touting a
database backend as a good idea (I highly disagree), and if we do
this, we NEED a generic layer to support any sane database format, not
just one specific thing. Using a flat-file database is a better
option, but here people seem to think sqlite is a good idea (it's not)
- there are many flat-file schemes that can drastically outperform
There are many many other options, and I think it's worth at least
_supplying_ multiple backends, even if they're not used. So gdbm is
More information about the pacman-dev