Qt3 still broken (compat-headers), what to do?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi ho, it's time for another rant from me regarding the libqt3-compat-headers
split. This time my ex-housemate has been hit by the problem: she's just
started working with Qt, and lo and behold she received a missing header
compile error. She didn't look through README.Debian for the fix since it
didn't occur to her that debian would deliberately break the Qt development
environment like this.
The motivation for this post is that I *really* want this issue fixed for
sarge, lest we go through the whole debacle once more for users upgrading
between stable releases.
The contents of this email are as follows:
1. Problem description
2. Timeline
3. What can be done
If you don't want to read this entire email, feel free to skip directly to
section 3 where I discuss a possible Qt NMU amongst other things and ask for
opinions. Otherwise, off we go.
1. Problem description
Qt3 as produced by upstream includes a number of headers, including both
modern headers and legacy headers to ease the Qt2 -> Qt3 transition.
In debian these headers are split into libqt3-headers and
libqt3-compat-headers. There is *nothing* in the package management system
to suggest to users that they might want libqt3-compat-headers. In
particular, the main development packages (libqt3-mt-dev and libqt3-dev)
depend on libqt3-headers but don't even mention libqt3-compat-headers (no
depends, recommends or suggests).
Several 3rd-party Qt apps still use these legacy headers. If a user tries to
build one of these apps they get a compile error (missing header) and are
given no further information. To find out how to fix this problem they have
to (i) post to a mailing list or read an online FAQ, or (ii) think that
perhaps this is a debian problem, not a Qt problem, and then think to read
the README.Debian to see how and why debian introduced this breakage.
The original motivation for this split was to encourage upstream developers to
transition their apps from Qt2 to Qt3 headers, and to encourage users to
hassle upstream developers because their debian build no longer works.
The consequences of this split are that:
(i) some upstream apps have migrated from Qt2 to Qt3 headers;
(ii) many users have been confused by compile errors, as evidenced by posts to
debian-kde over the past months;
(iii) many people have simply installed libqt3-compat-headers to fix the
problem, rendering the package split meaningless (since legacy headers in
other Qt apps are no longer identified).
There is a much less painful way to encourage upstream developers to migrate
their headers; this is to run fixkdeincludes over the sources and email
upstream the results. Of course this doesn't put the upstream developers
under pressure from their users to fix what are debian-specific compile
errors, which is presumably why the package split was used instead.
The less harmful solution of putting #warnings in the legacy headers was
proposed; this was rejected by the Qt maintainers because it differs from
upstream's Qt release. Why silently moving all of the legacy headers into a
separate not-installed-by-default package is more faithful to upstream's Qt
release I do not understand.
Most of the noise regarding this problem has died down, almost certainly
because people who have already transitioned from woody to sid have
experienced the problem, posted to mailing lists or read list archives and
installed libqt3-compat-headers to get rid of the errors.
Presumably the noise will start up again when we release sarge and get another
round of errors and confusion from people upgrading from woody. I would like
this issue resolved before this happens.
2. Timeline
3 Feb 2003: Headers are split; libqt3-compat-headers is born.
27 Feb 2003: The header split is discussed on -devel and -kde:
http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg01724.html
With the exception of a couple of vocal people (such as the Qt maintainers),
IIRC most developers disagreed with the split.
17 Mar 2003: Ralf indicates in #184084 that the problem will be fixed, i.e.,
that libqt3-compat-headers will be introduced as a dependency for libqt3-dev
and libqt3-mt-dev. This fix can be observed in KDE CVS (where the Qt
packaging files are kept).
10 May 2003: A new Qt3 is uploaded to debian without the promised
dependencies.
16 May 2003: These dependencies are removed from KDE CVS by the Qt maintainer:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/qt-copy/debian/control.diff?r1=1.56&r2=1.57&f=h
The changes were never uploaded to debian.
3. What can be done
I have been prodding on this issue for several months now with repeated posts
to mailing lists and the Qt maintainers. A bug has been open (#184084) for
this issue since 9 March.
Despite what seems to be an strong majority of opinion against the split,
nothing has been done, even though the fix is so utterly trivial (add
libqt3-compat-headers to the Depends lines in debian/control).
It seems then that our options are as follows.
(i) Wait for the Qt maintainers to upload a fix.
(ii) Do an NMU for Qt, despite the fact that this bug is not release-critical.
(iii) Resort to the technical committee.
(iv) Keep the package split and release sarge with a broken Qt development
environment.
Several months of experience suggest that (i) does not promise success.
Option (iii) seems rather heavy-handed to me. And I am loathe to see us
reach (iv), cementing debian as the only distribution with a deliberately
broken Qt.
I'd thus like to propose (ii) as the best solution. I realise this is not an
RC bug; technically it's not debian's problem but the upstream Qt app's
problem. Nevertheless, as it stands users are expected to divine the fact
that debian has deliberately broken Qt, that they should look in
README.Debian for a fix and that they are morally expected to tell upstream
that their code is wrong (after all, that's why they were forced through this
hassle in the first place).
I therefore see this is as a "release-critical usability problem", which the
BTS and policy have no formal concept of.
I'll be happy to do the NMU myself and wear the consequences if necessary.
Though I would first like to elicit opinions from other developers on whether
they feel this is the correct action to take at this point.
So. Do people support this move or not?
Ben.
- --
Ben Burton
bab@debian.org
Public Key: finger bab@db.debian.org
A handful of lovers and loved ones, fighting shoulder to shoulder, could
rout a whole army. For a lover to be seen by his beloved forsaking the
ranks or throwing away his weapons would be unbearable. He would rather
a thousand times die than be so humiliated.
- Plato, The Symposium (4th century BC)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/ENcuMQNuxza4YcERAiywAJ9P+92XuWbaDmQEGe49QpcQjZT71QCgjseB
nA8kVe2xwTYKKUitekKl0QQ=
=EQvF
-----END PGP SIGNATURE-----
Reply to: