[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: On the matter of Qt packaging


On Thu, Feb 06, 2003 at 05:13:32PM +0100, Ralf Nolden wrote:

> > I don't think it is Debian's business to decide which header files are
> > to be installed or not. If they are installed by "make install", they
> > should be packaged, if not, then not.

> Works for automake packages. Doesn't for Qt, Qt-Embedded and QSA. Trolltech 
> has its own buildsystem that focuses on what their customers need. Those only 
> compile and use $QTDIR.

Erm, the headers that are installed by "make install" are obviously the
public API. If their customers need access to private APIs, then these
APIs aren't private anymore. If their customers need access to obsolete
APIs, then these APIs aren't really obsolete.

Point is, Debian needs to provide the same API as the rest of the world
does, or programs developed in the rest of the world will fail to
compile on Debian systems.

> > The only thing a Debian maintainer *may* do if she knows what she is
> > doing is split functional components.

> That's what we do.

Who is "we"?

> We split up a) the headers to classes that are compiled in 
> the library b) headers to classes which are configured as plugins (thus can't 
> be linked against in the standard case, use the plugin interface) c) package 
> away headers that are for compatibility reasons available but subject to 
> removal.

As long as you can install all headers, this is okay, if you want to do
the work. However I think this is clearly optional and cannot be forced
on someone else who volunteered to do the job. You haven't submitted a
patch, have you?

> > Hrm, maybe someone could talk to the Trolls and convince them to make a
> > unique marker in these files -- Like a comment with the md5sum[1] of the
> > word "obsolete". Then one could know which headers are obsolete. Again,
> > deciding that is not the distibutor's task.

> We have the clue how to do it why shouldn't we do it ?

Because we could also patch Qt to use RTTI to do runtime type checks
instead of the strange string comparisons Qt uses for compatibility with
compilers that cannot do RTTI. We also have the clue to do that, why
don't we?

> > Another case of private headers made public. Again, this is upstream's
> > mess to clean up, probably by issuing a #warning and removing the header
> > in the next major release.

> See above. It's a matter of TT's customers. Free Software geeks aren't 
> customers. We can ask to change things for the better and help them out 
> (which we do) but packaging is our job, not theirs.

Have you asked them already? If yes, what was their response. If no, why

> > What are the other distributions doing? If Debian followed your advice,
> > would programs compiled on Debian boxen still run on a RH or SuSE box?

> Yes, they would. We'd even help other distros because they can shrink their Qt 
> library to the minimum and configure everything possible as plugins as 
> intended by TrollTech long-term.

I'm not sure TT intends to do anything -- after all, their paying
customers are

 - embedded folks who think plugins are a waste of resources
 - software companies that want to have a Linux by-product that looks
   like the Windows version.

IF they removed the direct access to things like QWindowsStyle, they
would piss off exactly their paying customers who need to rewrite their
programs at this point.

GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4

Attachment: pgpxHyx1mTQLG.pgp
Description: PGP signature

Reply to: