[Rpm-maint] Making rpm depend on glib?

[Ralf Corsepius]

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.
c.f. below.

> 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
failure".

But you are probably right, this is probably a different class of
embedded systems than the class of embedded systems which would like to
use rpm.

> Thoughts?
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.

Ralf