[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

On the matter of Qt packaging

Hash: SHA1


I'd like to sum something up which probably is the cause for some discussion 
here and I'd like to let it stay technical before flaming anyone. So if you 
write replies, please give it a try to stick to technical details (although 
parts of this mail is probably more a rant than anything else).

The subject says it - on the matter of Qt packaging.

Before I started to get involved in that, the Qt packages were a complete mess 
from the technical point of view, much more from the programmers point of 
view. As Martin Loschwitz aka Madkiss is the current maintainer of the 
package, I tried to work with him to resolve the issues that I saw from the 
programming and users's point of view so the Qt packages would become 

FYI, KDE's CVS has a module qt-copy. This one holds the debian dir for 
packaging, which led to the misconclusion that one just needs to package 
qt-copy and be done with Qt. Martin has a CVS account at KDE (so do I, 
obviously), just that he claimed the exclusive right to commit there or yell 
at anyone doing changes without his consent. While I considered this to be 
quite childish, I gave my best on my patience to work with him even though I 
could have done all changes there myself.

Now, quite a lot of stuff has been done since Martin didn't want to listen but 
gave it a second thought every other day. The result was that I had to 
explain things over and over again for every single file to be packaged 
where. With this week, there are still issues in Qt that IMHO need to be 
resolved to make it work for everyone, but apparently Martin put me on ignore 
on IRC, so I only have the option to package up my own Qt packages and work 
inside qt-copy/debian myself. Before doing so and giving up any hope that I 
can't educate a 16 year old non-programmer to work with a programmer, I can 
only turn to debian-devel to ask around if anyone can teach a new maintainer 
to listen what seems to be optimal to make his package perfect.

Here are the issues that are still open:

- - split up libqt3-headers into libqt3-headers and libqt3-compat-headers since 
about 30% of the Qt-headers are for compatibility to Qt 1.x and 2.x versions 
and not part of the official Qt3 API anymore. If a packager maintains a 
package that requires the compat files he should then notify upstream to fix 
the includes he uses and until then use libqt3-compat-headers in his 

- - the missing symlinks from /usr/share/qt3/lib to /usr/lib for libqui and the 
wrong installation location of the *.prl files that ship with Qt (currently 
installed to /usr/lib, having a similar function like *.la files but only 
work with Qt's own qmake stuff, so need to be placed in /usr/share/qt3/lib 

- - the IMHO more than necessary splitting off of the static libraries libqt.a 
and libqt-mt.a into a separate package libqt3-static-dev. Each has about 10 
MB of size and currently cover 99,9% of the size of the libqt3-dev and 
libqt3-mt-dev packages that are needed for packaging any Qt application. This 
means that 99,9% of the traffic caused by these -dev packages is wasted, 
because there is currently absolutely noone that needs static Qt libraries. 
Besides, static linkage is only done if the symlink to the shared library 
isn't found either, so a packager/developer who wants to do static linking 
with Qt needs to manipulate his system anyway with removing the symlinks from 
libqt3-*dev to the shared libraries. Of course, Martin's objection here is 
that this is a "debian policy" to always package the static libs with the 
- -dev package, but there are already exceptions where static libs were 
packaged in a static-dev package in Debian and here it would make sense to do 
that also.

- - the installation location of certain *.desktop files for applications 
shipping with Qt (namely assistant and qtconfig) still isn't correct

- - the HTML documentation is still missing for qmake in the qt3-dev-tools 

- - the Qt logo is only present in the qt3-doc package. This means that for all 
Qt applications' documentation the HTML pages have empty places where the Qt 
logo should be unless qt3-doc is installed. I told Martin how to change that 
by renaming the logo file for each tool's package and sed' the HTML files, 
but he refused to do so unless I'm providing the proper regexp for doing so.

My summary is that the current state of the Qt package only got elaborated 
since I started to tell him how to do things and now he's giving up at 90% of 
the work. My conclusion is that I merely wasted 3 weeks of time with a debian 
packager and if Martin doesn't get back on track to fix the issues that will 
surely be the last time I wasted my time with anything that has to do with 
telling debian packagers how to package the packages they are so proud of to 
be maintainers for in measures that their ego requires.

Any comments on getting the remaining issues solved are welcome.

Yours sincerely,

- -- 
We're not a company, we just produce better code at less costs.
- --------------------------------------------------------------------
Ralf Nolden

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org
Version: GnuPG v1.2.1 (GNU/Linux)


Reply to: