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

Qt3 still broken (compat-headers), what to do?

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

16 May 2003: These dependencies are removed from KDE CVS by the Qt maintainer:
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 

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 Burton
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)

Version: GnuPG v1.2.2 (GNU/Linux)


Reply to: