[Rpm-maint] Making rpm depend on glib?

[Panu Matilainen]

On Thu, 14 Feb 2008, James Antill 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().
>
> Can rpm handle the "malloc-failure is abort()" design that glib uses?
> If so, it seems like a no brainer to me.

That's pretty much the design rpm uses already, it has it's own xmalloc(), 
xcalloc() etc calls that terminate the process via exit() with no chance 
to recover if allocation fails. That, or just plain crash-n-burn in case 
alloca() fails.

Whether that's "handling" is another question, but at least glib behavior 
isn't any worse.

>> 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.
>
> However one thing I would say is that the glib string API isn't very
> "mature" and if that's one of your main pain points I'd humbly recommend
> ustr instead (it's in Fedora), which also doesn't have the
> malloc-failure design problem.

Strings are one, not necessarily the main point. Just some preliminary 
investigation atm. Thanks for the pointer though, I'd never even heard of 
ustr before now - worth checking at least.

 	- Panu -