[Rpm-maint] Making rpm depend on glib?

[Ralf Corsepius]

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

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

Avoidable: yes.
Necessary: 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.

Ralf