glib in kdesupport: yes or no?

[Rob Kaper]

On Sun, Mar 09, 2003 at 09:42:22AM +0100, Stefan Westerfeld wrote:
> I am not sure whether I should put glib-2.0 in kdesupport, basically,
> because I am not sure what the platforms KDE developers use are. Under
> most linux distributions, glib-2.0 should be available as package.
> However, under some other systems, glib-2.0 might not be packaged (i.e.
> windows, AIX).

I'm using KDE in a semi-embedded project where a couple of hundred extra k's
would not be welcome. Personally I'd welcome a small Arts Lite, which merges
streams and nothing more, for desktop use, drop-in replacable with Arts
Advanced, with every feature possible. Then I would not care if Arts
Advanced would depend on glib.

It has long been argued that most of the arts features are overkill for a
desktop environment anyway. Then again, I remember previous discussions
about this and I believe there were some convincing arguments against 'esd'
as well.

> I'd propose not adding it, because glib is part of the GNOME project. At this
> point in time, I see no distinction between KDE and GNOME any longer.

> And if you still think KDE and GNOME are seperate projects, and for that
> reason don't want to install glib-2.0 on your system, I think you're keeping
> up the illusion that KDE and GNOME are working on different goals. They are
> not. Thus, this is no valid reason for me.

It seems to be a valid reason to plenty of people.

Anyway, if KDE starts to depend on glib, I'll put monopd in kdegames adding
a dependency on libmath++ and libcapsinetwork to KDE(-games) as well, just
to make a point. I know, monopd isn't geared towards KDE (the reason it's
seperate from Atlantik is to specifically allow a broader adoption), but
neither is arts, so that's no valid reason for me.

My opinion is that any code in KDE CVS (except qt-copy and kdesupport)
should be specifically geared towards KDE. If arts is not, it should not be
developed inside KDE CVS, regardless of whether we use it.

KDE has a very moderate amount of required dependencies and I'd like to keep
it that way unless we adopt a policy to change that. But if there's any way
there can be a lightweight arts to be included and an advanced one as
drop-in add-on replacement, that'll make me happy.

Rob
-- 
Rob Kaper     | "They that can give up essential liberty to obtain a little
cap at capsi.com | temporary safety deserve neither liberty nor safety."
www.capsi.com | - Benjamin Franklin, Historical Review of Pennsylvania, 1759
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030311/c0ac2a9f/attachment.sig>