[Rpm-maint] librpm feature/API request
Christian Grothoff
christian at grothoff.org
Tue Jul 22 09:34:31 UTC 2008
Hi there!
I'm the maintainer of GNU libextractor and I just updated the LE code to use
librpm -- we used to have a heavily hacked old version of librpm from 2002 as
part of our codebase.
During that change, I discovered that a problem that we had in 2002 with the
API (causing our old, specialized fork of the code) still persists: the
inability to just use librpm with a block of data (corresponding to an RPM
file) in memory.
Instead of having to give librpm a file handle, I would like to just pass
a "const char* buffer" and a "size_t size". Some of the GNU libextractor
users have the data in memory (and possibly never on disk).
The current hack that I used (the code is available at
https://gnunet.org/svn/Extractor/src/plugins/rpm/) is to create a pthread and
feed the RPM data to librpm using a pipe. This is incredibly ugly and I need
to mess with signals to properly terminate the thread -- which is also not
quite in line with how GNU libextractor plugins should behave.
Given that librpm already has some IO-abstractions in place, extending the API
like this should mostly require you to clean up the IO subsystem. The
current abstraction is internal and uses a global variable (struct with
function pointers to open/close/read/write, etc.), which is currently (AFAIK)
constant. Since LE is supposed to be reentrant (so we can not just change
global variables, even if you were to expose them), my suggestion would be to
move that global into the rpmtc and provide a function for setting it.
Naturally, I have no clue what else this might break, so this is just a
suggestion from an outsider... Please let me know should you change the API
so that I can update the LE code to take advantage.
Happy hacking!
Christian
More information about the Rpm-maint
mailing list