[Rpm-maint] Making rpm depend on glib?

Panu Matilainen pmatilai at redhat.com
Thu Feb 14 10:05:43 UTC 2008


Something I've been occasionally thinking of, and was again reminded by 
looking at the gcc __attribute__() compatibility macros of glib.

There are vast amounts of things in glib that would be highly useful in 
rpm: string-, file-, date/time-, internalization/unicode utilities, error 
reporting / logging, data types... For some of these rpm carries 
limited roll-your-own versions, others are just not there even if badly 
needed like a mallocing sprintf().

Using glib facilities for these would make many portability issues 
somebody elses problem (glib is supposed to be highly portable) and allow 
throwing out many of the roll-your-own helpers that have little or nothing 
to do with package management. Silly things like string buffer 
manipulation, even exposed in the rpm API.

The questionable part is the size of the thing, it's not exactly trivial:
[pmatilai at localhost ~]$ ls -l /lib64/libglib-2.0.so.0.1400.5
-rwxr-xr-x 1 root root 823936 2008-01-08 05:36 /lib64/libglib-2.0.so.0.1400.5

OTOH, the GTK/GNOME stack aside, all sorts of fairly low level items (on 
modern Linux) depend on it so it's quite likely to be present in installer 
images and such already. The size-issue is most likely a non-issue for 
anything but embedded systems. My guess is that glib is present on most of 
them too but that's a very uneducated guess, my experience with embedded 
systems is very very limited.

Thoughts?

 	- Panu -




More information about the Rpm-maint mailing list