Ralf, On Thu, Feb 06, 2003 at 01:41:28PM +0100, Ralf Nolden wrote: > 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. I don't think it is Debian's business to decide which header files are to be installed or not. If they are installed by "make install", they should be packaged, if not, then not. The only thing a Debian maintainer *may* do if she knows what she is doing is split functional components. > 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. Hrm, maybe someone could talk to the Trolls and convince them to make a unique marker in these files -- Like a comment with the md5sum[1] of the word "obsolete". Then one could know which headers are obsolete. Again, deciding that is not the distibutor's task. > 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. How about #warning This code uses the obsolete header file <qapp.h>. Please consider #warning switching to qapplication.h instead. > 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. Yes, upstream allowed that. Upstream will have to fix that. [...] > 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. Another case of private headers made public. Again, this is upstream's mess to clean up, probably by issuing a #warning and removing the header in the next major release. > 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. Erm, IIRC these headers are also available when the package is installed with "make install". Debian in this case followed the upstream authors, and I believe we cannot be blamed for being compatible. > 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. I suggest you find 3-4 volunteers first before proposing such a thing. BTW, the most sensible for everyone would be that the Trolls fixed their distribution so people wishing to fix things would not risk incompatibilities. Right now, you can compile stuff that was developed on a "make install"ed box on Debian, and I want that to stay this way in the future. > As you see, very much depends on the technical insight into the whole stuff > rather than just doing things simple. Yup. If the Trolls had that insight, they would not have installed their private headers. Please don't blame the packagers for remaining bug compatible. > 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_. What are the other distributions doing? If Debian followed your advice, would programs compiled on Debian boxen still run on a RH or SuSE box? If not, then sorry, we cannot do this, because that would disqualify Debian as a development platform. Simon [1] The word itself would probably not be a good indicator. -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
Attachment:
pgpFCfFUXbW6U.pgp
Description: PGP signature