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

Re: On the matter of Qt packaging

Hash: SHA1

Hi Brian,

While I have some understanding for your POV because it makes things a lot 
easier for the packager ( read: package /usr/include/qt/* ) it has some 
drawbacks, even for Debian, which is the exact reason to split it up. 

Looking at the current libqt3-headers package, you will find due to the 
wildcard a subdirectory /usr/include/qt/private. This contains the private 
header files that are only required for the build of Qt and are not part of 
the public API and thus doesn't belong there.

Second, looking into one of those files that I targeted for a compat-headers 
package, /usr/include/qt/qapp.h:

Compatibility file - should only be included by legacy code. 
It #includes the file which obsoletes this one.

The only code there is just #include "qapplication.h".

The result is that as long as you are providing this file in a headers 
package, developers are offered the possibility to use it as an include in 
their code, even if the application works with Qt 3. The files however, are 
target to removal any time in the future by Qt upstream packages. In this 
case, the affected upstream program/package will be affected as soon as a new 
Qt release will drop those compatibility include set. Which essentially means 
that if by upload of the Qt package maintainer the built of these packages 
will fail for the affected package maintainer where we allowed upstream to 
use stuff that it shouldn't. 

Let me point out another scenario that is responsible for quite some mess with 
upstream packages that developers created and where packagers are responsible 
for: The style plugins. 

In the beginning of style plugins, people just used qwindowsstlye.h instead of 
using the correct stlye interface for plugins if they ever created something 
"special" for their application. Then those apps broke compiling as soon as a 
packager tried to package it when the styles were configured as plugins like 
they should be. With distros like SuSE things are quite simple: the packager 
of  Qt is in most cases the same as for the apps written with Qt. So they 
just compiled the plugins built-in, unnecessary bloating up the library just 
to avoid the breakage of one or two small applications and leaving the option 
open to the developers to misuse the styles. The same scenario counts for 
Debian now (everything possible is made as plugins to shrink libqt* to the 
minimum size so weaker machines still can handle a desktop), where my way 
with dealing is to notify upstream authors to correct their mistake so their 
packages compile on Debian, which works quite well.

If you don't want to go through those problems again, it is better to avoid 
them right ahead. If you offer a library, only offer the header files that 
are building the official API so all apps written from the day the developer 
gets the library+headers will work in the future. Not splitting up 
compatibility headers will result in problems for the distribution later 
because you're giving developers using the package in a certain way (but 
works for them) a blanco-cheque for doing things wrong. With some stuff I 
achieved a correction already by telling Martin which header files to package 
in a plugin-headers package so the files are still available for inspection 
by developers wanting to program their own plugins but not being part of the 
libqt3-headers package. This results in if an upstream package misuses code 
that is configured as plugins, the compile failure will happen at 
preprocessor time, not at linker time. Experienced packagers and developers 
will know the cause for this and it saves quite some time to track down 
problems. The same counts for the packaging of qwidgetfactory.h only with 
libqt3-mt-dev because only that package includes libqui.so symlinks (libqui 
is linked against libqt3-mt and needed by designer which is also linked 
against libqt-mt but can't be provided with the nonthreaded version without 
collisions, that's a TT feature)

My POV and result is that the packagers are most often responsible for later 
problems of packaging when it comes to packaging development packages. Giving 
developers things that they shouldn't be given will always result in 
developers doing things wrong sooner or later without them even knowing about 

To avoid this confusion, heck, I would even offer to sort out those things by 
myself and help the situation long-term with this. I would propose a 3 to 4 
people team that schedules and manages all Qt packages from Trolltech in a 
way that it makes the most sense for everyone and I myself would even take 
care of a package and sorting out this mess.

As you see, very much depends on the technical insight into the whole stuff 
rather than just doing things simple. Then we could have spared all the work 
and just say, what the heck, it works as long as you install *all* Qt 
packages and don't use any other Qt version than what you need. And I can't 
imagine that anyone seriously wants this situation to continue into the next 
distribution if you know that you can help it by making things correct _now_.


- -- 
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: