> Almost all of KDE CVS should be working without the compat-headers ...
I'm not referring to KDE CVS specifically; I believe perfectly that package maintainers are capable of sorting out this situation in time. The thing is that most users *aren't* package maintainers, and most people who build some application that they download from the net *aren't* the developer of that application. > It's simply doable by runnning fixincludes from kdesdk in the source > directory to make apps/packages compile. This is a job that is too easy for > users, packagers and developers without having to recompile everything ... Sure, but I'll argue that this isn't something we should force users to do. It's the job of the developer to remove legacy headers from their applications. I don't think debian should be forcing users to discover and then work around these problems. > > 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. I don't believe that -DQT_NO_COMPAT should be made into a default option. Again this would mean we force the users to be responsible for updating the developers' legacy code. > Ben, I know that it's been a bit troublesome but OTOH we could have just used > libqt3-compat-headers and do nothing in KDE CVS. Instead, we used fixincludes > to fix the BRANCH so that it doesn't depend on the package. Sure. But we, or the KDE developers could have done that just as easily without splitting the header packages. As you say, it's simple - just run "fixincludes", send your patches upstream and we improve the quality of free software. Without having to split the Qt header packages and cause needless confusion for users trying to compile other software on debian boxes. > And compiling and packaging isn't the only thing that Qt is intended to > be good for, it's mainly for developers developing new software :) Well, no. It's for (a) developers to write software, and (b) users to recompile and/or tweak that software. You're essentially asking that we break (b) in certain situations so that (a) results in less legacy code. Again, I applaud your motives. I nevertheless don't believe that Debian should be the body that polices legacy headers. We should make a distribution where compliation just works, and those of us who wish to encourage better code can simply rebuild apps on our own with -DQT_NO_COMPAT and/or run fixincludes, and pass the patches upstream. > It had to be done sooner or later ... No, I don't think it did, not until TrollTech releases a new Qt upstream with a similar level of anti-legacy enforcement. As it stands now, with a default Qt development environment installed, Qt apps can break on debian where they work everywhere else. > So it seems to me that a good idea would be to include them in the usual > -dev package, and then patch them with #warning directives that say > "foo.h is deprecated and may disappear in the future; please use bar.h". I'm very happy with this proposal. It means builds still work under debian just like every other distribution, but it also means that users and/or developers are made aware of the use of legacy headers, which is your motive AIUI. Ben. :)
