On Wed, Feb 26, 2003 at 08:01:51PM -0500, Matt Zimmerman wrote: > On Thu, Feb 27, 2003 at 12:16:44AM +1100, Ben Burton wrote: > > 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. > I do not think that the package split makes sense. > It is not justifiable to burden Debian users and Debian package maintainers > with these legacy issues. A deprecated header file should issue a #warning > explaining that it is deprecated (and, ideally, what replaces it). Simply > breaking the builds of a lot of existing software (packaged and not) does > not make sense here. Even better, if you look inside the replacement headers, you'll find that the *official* headers contain backwards-compatible #defines for all of the deprecated classes. So you can #include <qmemarray.h>, and continue using QArray as your class type. So what do we gain by weaning developers off the old headers again? -- Steve Langasek postmodern programmer
Attachment:
pgpaVWb_P6XLM.pgp
Description: PGP signature