[Rpm-maint] Making rpm depend on glib?
rc040203 at freenet.de
Thu Feb 14 13:08:41 UTC 2008
On Thu, 2008-02-14 at 12:05 +0200, Panu Matilainen wrote:
> 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().
Why is such thing badly needed?
I don't see such a need. Quite opposite, I think using such thing (and
related friends, such as alloca) are design-flaws which should be
removed ASAP, which would likely solve a lot of issues.
> 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.
Well, being involved into embedded systems for a long time, I can't
avoid having to disagree. For embedded systems any byte in first place
"just adds costs" and in second place is a "potential source of
But you are probably right, this is probably a different class of
embedded systems than the class of embedded systems which would like to
I am opposed to it.
As you correctly say, using glib primarily shifts issues around but to
solve them and adds another source of future problems. It's the old
"wrapper", "adding a layer", "rucksacking" approach.
More information about the Rpm-maint