is new lib dependency possible for 3.5.2?
arysin at myrealbox.com
Sun Jan 29 17:47:58 GMT 2006
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.
> 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.
More information about the kde-core-devel