[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