[pacman-dev] Backend DB [was: Hypotetic pacman's db structure]

Miklos Vajna vmiklos at frugalware.org
Fri Nov 9 17:10:20 EST 2007

On Fri, Nov 09, 2007 at 03:28:33PM -0600, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> To probe your thoughts a bit further, if the world were ideal, what
> kind of backend would YOU go for?


good question. i actually like the current backend as it's easy to
repair. if you have a corrupted db and bdb's magic repair says it can't
fix.. say your data goodbye (i managed to do this with both my
bogofilter db and with my old rpm database, too)

if you look at git, they also had this problem, git operates with
many-many small files and they introduced packs (with indexes) to speed
up reading from the database

an idea i have: it would be interesting to see if this works for
pacman's db, too. like: the sync dbs are never modified, so the sync dbs
could be one single file: just files concatenated after each other,
and having an index to mark where an entry (which is a file atm) starts,
its length and maybe pkgname-pkgver (so by reading the index you would
get what you currently get by reading the dir only but no files)

for the local db, we could have a 'marked as deleted' bit for removed
entries then pacman-optimize could really remove those entires if it
hurts someone

ok, enough. i think it does not worth a big discussion, it would be
interesting after i implemented it and i have benchmarks to see how fast
it is, compared to the current implementation

pacman-1.0 proved that there is single-file db implementation that
doesn't work - it would be nice if i could provide one that does :)

ah and my additional problem with bdb is its size: 14M (compressed)

and finally one more argument for the current implementation: several
times i had a hdd crash when parts of the pacman db was affected during
fsck. and it was easy to solve. pacman -Qt, it printed 3 packages,
reinstall, and you're ready. afaik none of the single-file
implementations have this advantage

- VMiklos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/pacman-dev/attachments/20071109/2f2e577c/attachment.pgp>

More information about the pacman-dev mailing list