is new lib dependency possible for 3.5.2?

[Andriy Rysin]

Nicolas Goutte wrote:
> On Saturday 28 January 2006 04:17, Andriy Rysin wrote:
>   
> ...
>> It also would be nice to hear arguments against (indirect) dependency on
>> glib, especially taking to account that arts already depends on that and
>> nobody complained for years.
>>     
>
> Nobody? 
>
> You surely have missed the flame wars about it, when the glib dependecy was 
> introduced in arts. (And again when pkg-config started to be used in KDE...)
>
> In (very) short, the main critic is that Qt is offering similar classes, so 
> you end up with two implementations of similar things.
>   
ok, sorry, I've missed that but the dependency has been there for a 
while, but I don't see a reason bring that flame again

As to the main critic - the point is that if there's C library which I 
could use to (greatly) improve xkb configuration parsing for kxkb (we're 
talking about a dozen of bugs here) and later add new features for free, 
why would I care that it uses another low-level lib,  which depends only 
on glibc? By the way libxklavier also depends on libxml2 and libz. So 
the question is whether this will be a problem, because I would not like 
to discard the library just because it uses XML parser from libxml 
arguing we already have it in Qt?
I believe it'll be eternal problem if we are to use C-libraries of a bit 
higher level than glibc.

Also I've talked to libxklavier author and he agreed to maintain 
libxklavier branch without glib dependence for KDE 3.5.x but he'll be 
considering glib for next version of libxklavier which will be hopefully 
used in KDE4.

Andriy