Re: On the matter of Qt packaging
-----BEGIN PGP SIGNED MESSAGE-----
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
it.
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_.
Regards,
Ralf
- --
We're not a company, we just produce better code at less costs.
- --------------------------------------------------------------------
Ralf Nolden
nolden@kde.org
The K Desktop Environment The KDevelop Project
http://www.kde.org http://www.kdevelop.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+Qlf8u0nKi+w1Ky8RAq3vAJ9hJJhv4C66Jno30E1j9Js91lrbEgCfYwZB
eR4/+9waEIaRJILp1oVMpig=
=Jru5
-----END PGP SIGNATURE-----
Reply to: