Re: On the matter of Qt packaging
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Freitag, 7. Februar 2003 02:58, Simon Richter wrote:
> Ralf,
>
> 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.
Please have a very very close look into the Qt sourcepackages to form yourself
an opinion about what each file does. That's the work we're undertaking to
decide where to package what. TT customers have a commercially licensed Qt
that they build themselves and who's programs cannot run with the GPL'ed Qt
library so they have to ship their own version (that's the current situation
although it doesn't make much sense performance-wise).
>
> 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.
It does. It just moves compatibility headers and private headers into other
packages that allow maximum compatibility for older programs if you use those
packages as build-deps. The sense in sorting out the public API files into
the headers package is that we make sure that the programmers can be safe
with using those header files without having to go through each file to know
if it's public API or not. I think that is easy to understand :-)
>
> > > 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"?
Martin Loschwitz AKA Madkiss and I. Martin started to work with me yesterday
afternoon again and we'll hopefully finish up this mess tonight.
> > 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?
That's why I'm working together with Martin because if I had made a patch I
would have been ready with my own set of packages but can't be sure that he
takes the changes over. They require a lot of insight into Qt and all its
components so it was best to work together and teach him what belongs where.
> > 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?
That's a question that affects the runtime vilability of Qt and not the
packaging of files itself that are arch independent anyway.
> > 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
> not?
If you'd happen to know me closer you'd know that my daily work is constantly
involving developers working at TT and we are talking to resolve issues bit
by bit to make things easier in the future. I'm checking with them for
everything where I'm not 100% sure if my idea is correct.
> > 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
?? can you read my sentence above again ? TT provides the build system with an
idea how to use what, it's just up to the packager to configure it the right
way it's intended to be build.
> 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.
This is not about TT's paying customers, it's about configuring the GPL'ed Qt
for Debian and Linux in general as a central component in the best technical
manner possible for users and developers.
Ralf
>
> Simon
- --
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+Q4Uqu0nKi+w1Ky8RAr/dAJ9R+ZakbrSsDlYVN+wlLZ5nbXLgFQCgn56V
Jdq/HVh9m7mgh4MHAW4ykQ8=
=j8UV
-----END PGP SIGNATURE-----
Reply to: