Re: Rethinking Qt headers (should the header packages be recombined?)
> 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. :)
Reply to: