Moving KMail, KNode, Korn and related libraries to kdepim
bo at sonofthor.dk
Tue Jan 14 21:03:30 GMT 2003
On Tuesday 14 January 2003 21:35, Dirk Mueller wrote:
> On Die, 14 Jan 2003, Zack Rusin wrote:
> > - smtp, pop3, nntp, imap4 slaves are being moved to kdelibs.
> eh, why ?
> We had them in kdebase, then they were moved to kdelibs, then to
> kdenetwork, and now back to kdelibs ?
> People, this "we move it around" has a cost, and its not small, and its
> unnecessary as well.
Please note with this that noone seems to argue that the right place for
these slaves are in kdebase. That at least suggests that they're in the
wrong place right now. ( <=Hidden invitation for people to speak up if
they disagree )
There is a cost in moving, yes. But having code in the wrong place also
> It doesn't matter much where the kioslaves are, because they're not
> needed at compile time. They're only needed at *runtime*. The
> dependencies for *runtime* are the problem of the *distributors* who
> will probably split the stuff up anyway. Our CVS modules are far too
> monolithic to be usable for *users* (Classic example: who wants
> kpovmodeler just because he wants to use kiconedit?).
This is completely wrong! Right now a person who wants to use kmail with
an imap account has to install arts, kdelibs, kdebase and kmail (even
though he could trim this greatly by compiling from source). This way
kdebase becomes a requirement for running some of the applications, which
was *never* the way it was supposed to be. That it's not compiletime
dependent is a fact that is given way too much weight by KDE people and I
don't understand that - yes, it's very important not to go to the build
mess of other big projects, but moving these slaves doesn't change
anything in this area.
> so before we move it around yet another time, let me suggest to create
> a separate module for them. We can then map the directories into any
> module we want at a fixed, minimal cost. We should have done that years
That would IMHO be a bad idea. The only thing you would gain from this was
one more thing you need to install besides kdelibs. With this one, the
ioslaves are better placed in kdelibs.
> The same probably applies to kmail, which could very well be its own
> toplevel module with all its branches nowadays.
The choice to move it to kdepim is much driven by kroupware and kontact
and the fact that there is a lot of code dependency between the parts of
what will be in kdepim after the kmail move. kdepim will is a module that
consists almost entirely of very closely related apps now, and there is
no gain from splitting it up.
My reasons for advocating the move of the slaves are:
- Noone seems to think kdebase is the right place
- Mail related slaves conceptually belongs with the mail program
- If you want to run the kdepim/kdenetwork apps, you're forced to install
- There is really only a single argument against the move: "They have been
there for a long time"
With a project like kroupware_branch, the kdebase requirement really is
annoying. IMHO it shows that it's wrong to consider runtime dependency as
something less important than the compiletime dependency.
Bo Thorsen | Praestevejen 4
Senior Software Engineer | 5290 Marslev
Klarälvdalens Datakonsult | Denmark
More information about the kde-core-devel