FS#5328 - pacman+GDBM patch for review

Attached to Project: Pacman
Opened by Martin Devera (devik) - Thursday, 31 August 2006, 22:43 GMT
Last edited by Dan McGee (toofishes) - Sunday, 17 February 2008, 01:31 GMT
Task Type Feature Request
Category
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture not specified
Severity Medium
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hi,
after fighting with pacman to take minutes on our servers (and making it yet worse) I decided
to spend evening and add GDBM support. Not it can work with both. Database shrank from 46MB
to 1.5M and times from minutes to a few seconds.
You can select format by UseGDBM flag in pacman.conf.
Just now it works for me, -y op loads tar directly into DB (!) so no fragmentation of fs
occurs. I store whole text fragments into db to be maximaly compatible.
The only thing is to handle install script - it is not detected as I filled bad db->path..
well it is late here ;-)
Makefile changes are not in diff just now but they are easy.
(application/octet-stream)    pacman1.diff (19.2 KiB)
This task depends upon

Closed by  Dan McGee (toofishes)
Sunday, 17 February 2008, 01:31 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Too old to implement. If anyone wants to take a stab at it, then go right ahead, but we need to refactor libalpm a bit to accept multiple backends.
Comment by Roman Kyrylych (Romashka) - Monday, 04 September 2006, 10:19 GMT
This would be great to have pacman db stored in some database file instead of filesystem.
But I think that this will be only implemented in pacman 3.1. :( But then. I would like to see db based on sqlite.
Comment by Aaron Griffin (phrakture) - Thursday, 16 November 2006, 22:40 GMT
sqlite is gross. embedded sql statements are gross. I would prefer something like BDB _if_ this ever does happen
Comment by Roman Kyrylych (Romashka) - Friday, 17 November 2006, 10:55 GMT
Should additional backends be maintained separately from pacman's tree?
Comment by Aaron Griffin (phrakture) - Friday, 17 November 2006, 15:40 GMT
Probably not, but this patch is for pacman 2.X (I think), so I can't do much with it.
Comment by Martin Devera (devik) - Friday, 17 November 2006, 17:38 GMT
Yes it is against 2.9.8 (as I didn't know about 3.x developement before Roman told me). Regarding gdbm choice - it was 33k vs 980k shared lib and stability of the interface. Yes there is no transactional recovery but hey, 2MB database file .. one can do a backup time from time or implement master db file plus "changes only" extra file and merge them time from time (where the merge would be done into separate file and atomicaly renamed then).
I'll try to port it to new pacman code one I find some time.
Comment by Aaron Griffin (phrakture) - Friday, 17 November 2006, 17:51 GMT
For the record, porting to the new pacman code simply requires you to provide a be_gdbm.c file which matches the be_files.c interface. The build process doesn't really have a way to specify the backend (yet) as there's only one backend.
Comment by Dan McGee (toofishes) - Sunday, 17 February 2008, 01:30 GMT
Wow, this is hopelessly outdated unfortunately. I'm going to close it as we can't do a whole lot anymore with it.

Loading...