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:
[EMAIL PROTECTED] ~]$ 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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
