is new lib dependency possible for 3.5.2?

[Leo Savernik]

Am Sonntag, 29. Januar 2006 22:25 schrieb Lubos Lunak:
[...]
>  You surely must be confusing Glib with Gtk here. Glib is the C equivalent
> of C++ STL. So minus the GNOME thingy this all can already happen anyway.

Not quite, since when does stl provide an event loop or mutexes? But QtCore 
does, so those are the equivalents to compare.

>
> Besides, we wouldn't have a hard dependency on glib, because first of all
> it'd be needed only for those people who don't happen to live in US/UK or
> Finland (SCNR), and second we'd have a dependency on libxklavier. Okay,
> libxklavier might depend on glib, but don't you have at least a bit pity on
> those poor C developers?

The more dependencies we introduce through the backdoor the more the 
impression appears that KDE as a whole depends on glib. By the time when 
removing glib leaves us with an unusable KDE, we've exceeded this limit.
>
>  If lixklavier brings in glib, then I still fail to see the big deal. If
> you want to complain about glib being heavy or something similarly silly,
> just have a look at ldd of some KDE app one day. If you want to try
> something like "chances of bugs in the lib being fixable by KDE developers
> without needing barf bags", then you're already late too, we've always had
> deps like that (does somebody know if George jumps when he hears "OpenSSL"?
> I've never tried in person). 

Afaik, OpenSSL is now dlopened. If kxbd/whatever did the same with glib, I 
couldn't care less.

> And, if you want to argue because of possible 
> political problems with our dependencies, then you're definitely very very
> late.

The glib problem appeared as soon as arts introduced a dependency on it. By 
that time, I wasn't even a KDE developer. So it sounds somewhat presumtuous 
to pretend the issue has been brought up "late".
>
>  Besides, since Andriy wants to replace some already existing code with
> libxklavier, I'm quite sure he can add some --disable-glib #ifdef for you
> so that you can maintain that while he's busy doing something useful.
> Problem solved.

When I asked whether it would introduce a glib dependency, the answer was no. 
So ok. Not nice to sneak in a dependency in a stable series, but ok. Then the 
discussion turned into a direction as if it were already set that libxklavier 
depends on glib.
>
> > So it uses up twice the RAM and is twice as slow.
>
>  Yeah, right. Incidentally ... well, soon.

Noo! KDE forces me to upgrade my hardware ;-) (full truth: staying with 
wind*ws would have forced me already).
>
> > Why going with the cheap copy when you can have the original?". This
> > statement is full of lies, but it's called marketing for a reason.
>
>  Hmm. So we stay away from Glib and people suddenly run out of lies against
> us. What a wonderful world do we live in.

I think it suffices not to deliver the ammuntion fired against us.

mfg
	Leo