-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mittwoch, 26. Februar 2003 23:15, Ben Burton wrote: > > 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, I always appreciate your work but I think from the developers perspective you just need to have a way to get the legacy headers out of the way. And the README.Debian explains *in detail* that if an app doesn't compile, install the compat-headers package. That's that, and that was a goal that was desired. So if we revert this and put the legacy headers back, even change them, which I consider to be even more evil than anything else because you're supposed to package the code and not to put your own stuff into it, then the whole point of 4 weeks of hard work was pretty pointless. It's as simple as reading README.Debian if something doesn't compile. Ralf > > Ben. :) - -- We're not a company, we just produce better code at less costs. - -------------------------------------------------------------------- Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XUNqu0nKi+w1Ky8RAjDtAKCIkTsnNhuas8p4csrBkvOXs9x+CQCeP057 o5gDP5kvTHzvM9evc73gq+g= =9DLH -----END PGP SIGNATURE-----
