RFC: Splitting Qt4 packages and implications of this

[Jarosław Staniek]

We know the benefits of having splitted Qt4 into gui and nongui libs.
Now, the question is: what's up at the packaging level?

We're not able to install a system without X11 dependency and be able to 
develop client or server solutions using Qt. This adds a penalty for Qt users 
from the very beginning compared to Java and .NET, doesn't it?

Quick search showed me Qt4 package as destributors provide it, is a the same 
monolyth as Qt3 was. We have only a runtime benefit, the OS is still bloated 
unless a user decodes to break the dependencies and remove the "desktop".

The question put to the extreme: what about moving kdecore to a separate package?

Of course I am not talking about dealing with packages creation - the general 
question is rather: should we and TT have a clear message (read: 
README.PACKAGERS file) stating that it's recommended to split Qt4 (and/or 
kdelibs) into separate packages, to get better modularity.

Unix OSes are quite modular by design, so it's not something normal than the 
upcoming Longhorn servers are going to have entirely GUI-less deployment 
options and we are loosing this option.

You can ask "what are you talking about when I've not seen a Qt-based server 
solution". My answer is: maybe there's a chicken-egg problem caused by 
X11-dependency?

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
  KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org