[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