Rethinking Qt headers (should the header packages be recombined?)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(If you don't want to read this entire email, feel free to jump straight down
to [SUMMARY]).
Hi. So we've had a little time with the new Qt header structure (package
libqt3-headers containing the primary Qt headers and package
libqt3-compat-headers containing legacy headers for compatibility purposes),
and I'm not entirely sure this is being done correctly.
The situation as it stands is this: various Qt headers have been deprecated,
but are still used throughout a variety of Qt apps (including the current KDE
release and a large number of third-party KDE apps). The upstream Qt still
provides these deprecated headers, which simply #include the new headers that
replace them.
To be able to build a package that uses these deprecated headers, you must
install the separate package libqt3-compat-headers, in addition to the normal
libqt3-headers. None of libqt3-dev, libqt3-mt-dev nor kdelibs4-dev depend on
this libqt3-compat-headers.
The reason (as I understand it) for splitting out these headers is so that
developers recognise that their code uses legacy headers and so they are
prompted into updating their code to use the newer headers instead.
The consequences I see are as follows. Say a user doesn't have
libqt3-compat-headers installed (since there's no obvious reason to have it
installed; none of the usual -dev packages depend on it). They download a
random Qt/KDE application to build, and it doesn't compile. They're
confused, since it builds everywhere else under Qt3. After some rummaging
around, they discover that oh, on a *debian* system you need the extra
libqt3-compat-headers package. The user installs libqt3-compat-headers so
that it builds properly, and if they're nice they'll even notify the upstream
developer that their application uses legacy headers.
On the other hand, say a user *does* have libqt3-compat-headers installed. In
this case they see no benefit from the package split at all, since everything
builds smoothly, legacy headers or no.
[SUMMARY]
I do applaud the effort to remove legacy headers from current Qt code.
However, I don't think the debian package management system is the correct
tool with which to do it. At the least it will cause confusion among users
(as it already seems to be doing AFAICT), and to gain full benefit from this
package split, you'd have to remember to uninstall libqt3-compat-headers
every time you want to test a new source tree for legacy headers.
There is a much better mechanism for testing a source tree for legacy headers;
this is the -DQT_NO_COMPAT compiler option, which forces a compile error when
a legacy header is used, and which can be used on an app-by-app basis instead
of a system-wide basis (such as package management).
So on reflection I'd be much happier if all the Qt headers were combined back
into the libqt3-headers package, or alternatively if libqt3-dev and
libqt3-mt-dev can be made to depend on libqt3-compat-headers.
Do other people have thoughts on this?
Ben. :)
- --
Ben Burton
bab@debian.org
Public Key: finger bab@db.debian.org
I like to think of Linux development as sort of a modified IETF style:
rough consensus and running code, with a sprinkle of holy penguin pee
when Linus thinks it's ready to ship.
- Seen on slashdot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+XL5AMQNuxza4YcERAgpNAJ9x027KIV1UH5NtiZQP7DpwvkmggwCfddny
EQ4eKKck0EnMtckRCkic3y0=
=zLCt
-----END PGP SIGNATURE-----
Reply to: