[Rpm-maint] Making rpm depend on glib?
rc040203 at freenet.de
Thu Feb 14 16:47:25 UTC 2008
On Thu, 2008-02-14 at 18:25 +0200, Panu Matilainen wrote:
> 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.
> >> 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?
Which common functionality?
Sane code should be based on libc as far as possible - I really don't
see why this should not be possible with a piece of low level SW such as
> 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?
Absolute no-go? No.
The later 2 are my arguments. IMO, you are about to pull-in a bloated
library, for the sake of exploiting 5% of it.
> 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.
IMO, it would be better to encapsulate those 5% into rpm guts, trim them
down to the set of absolutely minimally required functionality and
simultaneously clean up rpm's code.
I would not be surprised if close to NULL would remain.
More information about the Rpm-maint