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:
[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.
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 -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
