The kdebase purpose (Was: Re: Moving KMail, KNode, Korn and related libraries to kdepim)

[Adriaan de Groot]

[Message intended as discussion summary. If anything, I side a little with
the opponents of drastic moves.]

On Wed, 15 Jan 2003, Bo Thorsen wrote:
> On Wednesday 15 January 2003 10:53, David Pashley wrote:
> > On Wednesday 15 January 2003 07:51, Bo Thorsen wrote:
> > > KDE is kdelibs and kdebase. And then there's a bunch of optional
> > > stuff. And arts, which I'll leave out of this discussion.
> >
> > FYI:
> >

[David lists the Debian package dependencies for KMail]

> > As you can see the only think that kmail depends on from kdebase is the
> > kio-plugins. Everything else is kdelibs or kdenetwork.
>
> Yes, that's the whole point. kmail doesn't have to depend on kdebase if
> the ioslaves were placed in a sane place. libs or network will both do.

[What were we discussing again?]

Here we're confusing the dependencies between binary packages and CVS
modules again. This discussion is _not_ about what the dependencies of the
binary packages are. That's something for distributions to sort out.
(FWIW, the FreeBSD team just packages up CVS modules as a whole except for
i18n, and we've had about 4 complaints in two years about it. And our
kdenetwork package depends on kdebase.).

This discussion is about dependencies - both compile and runtime - between
CVS modules for people that want to build a working KDE desktop from
source. CVS source, no less. The KMail move muddies the waters in this
discussion as well. Let's deal with that first.

KMail is being moved because:
* There is much code overlap between it and some pim apps.
* (um, was there another reason?)

This has little to do with run or build-time dependencies. Just code
sharing. Of course, there are other ways of achieving code-sharing, but
they introduce more build time dependencies (namely, kdepim and kmail both
depend on some third collection of code). Hence, the KMail move muddies
the waters.


[Run-Time and Build-time Dependencies]

Let's reiterate the build-time dependency tree for a bunch of KDE's CVS
modules (note this doesn't have anything to do with individual
applications, and excuse the ASCII art):

arts <- kdelibs <- kdebase

AFAIK, both kdenetwork and kdepim _can_ build without base, so we get

arts <- kdelibs <- kdenetwork
                <- kdepim

as well. However, _runtime_, for certain values of "useful desktop", we
get the following:

arts <- kdelibs <- kdebase <- ( kdenetwork <-> kdepim )

Yes, that's two-way dependency between pim and network. KPilot needs
KMail. KMail needs KAddressbook.




Now, the arguments I've heard for moving IOSlaves around are:
* Runtime dependencies between KDE CVS modules are reduced.
* Run/build time dependencies between 3rd-party apps and KDE CVS modules
  may be reduced.

Arguments against:
* "No way", says Coolo.
* Where would they move to sensibly?
* Who _cares_ about these build-time dependencies, anyway? (Neil just said
  that, I think).


Proponents of moving seem to base their arguments on counting the _number_
of dependencies, opponents count the size. I mean, if ioslaves move to
libs, libs gets bigger and we're sure to get people whining about the size
of libs then (I want to develop a KDE app but libs is so bloated with
IOslaves, when all I need is libkdecore and libkio).

I'm inclined to side with the opponents of moves. People who are building
from source - early adopters, testers, etc. - should _KNOW_ what they are
doing. And that means that they also should know what's where, and don't
_have_ to check out all of a module to make it go. This:
	cvs co kde-common
	cvs co -l kdenetwork
	( cd kdenetwork ; ln -s ../kde-common/admin . )
	cvs co kdenetwork/kmail
should make sense to such people.


[What about other modules?]

Now what about _convoluting_ the dependency tree? As Dirk (IIRC) pointed
out,. you can map any directory on the server into some CVS module - like
we do with admin/. So if instead of moving the IOSlaves into libs, we move
them into a _NEW_ CVS module kdeioslaves (for lack of an imaginative name,
like dotNET) then we get the following _runtime_ dependency graph:

arts <- kdelibs <- kdeioslave <- anything that needs ioslaves
                              <- kdebase

Ick, ick, extra runtime dependency! (Only for kdebase - the number of
dependency modules for other modules remains the same, since
kdeioslaves replaces kdebase) But _distributors_ take care of that
for regular folks. For people building from CVS, the _number_ of CVS
modules to check out has increased, but the _size_ hasn't (hardly - you
may get an extra admin/ there). Again, if you're such a die-hard that
you're building KDE from CVS sources, you should know how to deal with
this. If you're a 3rd-party developer, then you don't need these CVS
modules either, you can get the devel pacakages from your distro.


[What's this about KDE-as-a-platform?]

We really should be careful in using words like "useful" in this
discussion. One man's useful (KPovModeler) is another man's line-noise (dd
if=/dev/random of=valuablediskspace count=298876). I suppose that women
feel the same way (but haven't asked any).

It looks like the _buildtime_ thing you could call KDE-as-a-platform is
just kdelibs. At runtime, though, you want all the IOslaves as well. And
plugins. And other stuff. So whenever we talk about KDE as a platform, we
should be careful about what time we're thinking of.




[What's your point?]

Down with woolly thinking! Up with clarity! Define your terminology, then
use it. Three cheers for Dirk.