-----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 [EMAIL PROTECTED] Public Key: finger [EMAIL PROTECTED] 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-----
