On Thu, Feb 27, 2003 at 12:16:44AM +1100, Ben Burton wrote: > > 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. > libqt3-dev/libqt3-mt-dev should not depend on libqt-3-compat-headers since that would, as you can probably imagine, completely nullify the package's intention. Anyway, the fact that kdelibs4-dev does not depend on the package yet is probably caused by the fact that it got not updated for recent changes. That is on calcs TODO, I guess. But that solution won't even be of long breath since, as far as I remember, Ralf said that he cut all references to headers from libqt3-compat-headers out of the KDE3-CVS (Was it in BRANCH or HEAD? Both? Don't remember, sorry.) > 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. > Correct, yes. > 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. > Uhm, optimistic person? I would actually call that the "Best case scenario"! ;) > > 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). > Having -DQT_NO_COMPAT as default compile option for qmake would probably not be too difficult to realize. I think adding this value to qmake.conf should almost do the job. Anyway, let's see what Ralf thinks about this issue. > Ben. :) -- .''`. Name: Martin Loschwitz : :' : E-Mail: madkiss@madkiss.org `. `'` www: http://www.madkiss.org/ `- Use Debian GNU/Linux - http://www.debian.org
Attachment:
pgp2VfyYVdPn4.pgp
Description: PGP signature