[Rpm-maint] Making rpm depend on glib?

Panu Matilainen pmatilai at redhat.com
Thu Feb 14 16:25:53 UTC 2008


On Thu, 14 Feb 2008, Ralf Corsepius wrote:
>
> 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?

Well, s/badly needed/would simplify a lot of things/ if you wish. It's not 
like one can't live without mallocing sprintf, and certainly that alone is 
nowhere near enough of a reason to drag in a library the size of rpm 
itself.

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

I mostly agree on alloca (because there's no way to handle failure) but 
manually precalculating string lengths is IMO just error-prone waste of 
programmer time most of the time. Yes, I've been spoiled by other 
languages and I'm lazy...

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

Yes, if you're even considering using rpm on an embedded system, the 
embedded system isn't very resource constrained :)

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

What's the point of using libraries for common functionality anyway?

Again, string handling alone is nowhere near enough of a reason to drag in 
something the size and complexity of glib. From what I've browsed the glib 
documentation, there would seem to be a lot of potential for replacing 
in-rpm implementations of all sorts of ad-hoc functionality. How much of 
that potential is realizable is a whole another question and needs much 
deeper investigation than just skimming through documentation.

Dunno if the message came across as inteded (probably not :), maybe a 
little bit of clarification is in order... The question really is: Is 
there some reason (such as the size) that would would make rpm using glib 
absolutely no-go? If no, then I'm going to spend a bit of time 
investigating how much worth would it be in reality before making any 
judgement this way or the other. The benefits would have to be big to be 
pretty big to seriously consider it.

 	- Panu -



More information about the Rpm-maint mailing list