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