On Fri, Nov 09, 2007 at 03:28:33PM -0600, Aaron Griffin <aaronmgriffin@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 thanks, - VMiklos