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

Re: On the matter of Qt packaging

Hash: SHA1


I would be very much in favor of Michael's proposal and would be willing to do 
that. As a reminder, Qt isn't just Qt3 alone. It takes quite some knowledge 
to collect and structure everything that is affected. Let me name things:

a) qt-x11-free-2.3.x  (the qt2 version)
b) qt-x11-free-3.1.x  (the qt3 version)
c) qt-embedded-2.3.x (libqte 2.x)
d) qt-embedded-3.1.x (libqte 3.x)

Additionally (which I want to file an ITP for) the new product from Trolltech, 
QSA (see www.trolltech.com for details) which will be GPL'ed also. 

The goal is to allow a mixture of any of those packages on an installation. 
There are some incompatibilities that one needs to be aware of and some 
requirements that the qt developer will suffer under due to the current 
packages; some of that even affects packagers.

The current situation requires libqt 2 to be there for packages that upstream 
didn't migrate yet to qt3-mt; but also requires libqt2 for using the Qt 2 
designer and moc. Those are required for Embedded development for Devices 
like the Sharp Zaurus or with Familiar on an iPaq for example, because the 
qt3-designer is incompatible to the qt2 designer output. The same counts for 
the moc (Meta Object Compiler) which under qt3 produces a different output 
than under qt2 and vice versa.

The wisest thing to do IMHO is to prepare qt3 in a way that it works best 
inside /usr/lib and /usr/bin while qt2, qt2e should be adapted and reworked 
so they can still be used in parallel. That means, that sooner or later one 
must find an agreement to use something like a QTDIR for those packages. 
Martin got convinced now to use /usr/share/qt3 now for qt-x11-free-3.1.1, so 
I would suggest /usr/share/qt2 for Qt 2.x, /usr/share/qt2e for Qt-embedded 
2.x and /usr/share/qt3e for Qt-Embedded 3.x. 

This is necessary sooner or later to avoid collisions at least with the moc, 
uic and the header files for each Qt version, so moc and uic must be 
available for 2.x in each's QTDIR/bin directory while only the current needed 
desktop version (3.x) places its tools into /usr/bin and installs the 
includes to /usr/include/qt.

When it comes to the qt2 designer, which seems to be the only exception that 
it *must* be available in /usr/bin, a renaming to qt2designer and an 
appropriate desktop file/menu entry + README addendum should fulfill the 
requirements. Renaming moc and uic is probably not possible because 
buildscripts will always pick up on moc and uic and nothing else. Packagers 
must be aware of that build scripts will primarily search in QTDIR/bin for 
those tools, so I think moving the qt 2 tools to there only solves most 
issues for packagers and developers.

Everyone a bit familar with the whole matter knows that this is a very 
difficult task to achieve, but I think everyone clearly understands that 
there is serious action needed to combine all possibilities in a way that it 
makes the most sense for the users and developers, even at the cost of having 
binaries like moc and uic not present in $PATH directly for Qt 2 anymore. A 
package that ships symlinks to the respective ones that collide with an 
according other symlink package for a qt 3 version would be the only way out 
of that to reduce the collisions to a minimum but ensure build requirements  
for packagers.


- -- 
We're not a company, we just produce better code at less costs.
- --------------------------------------------------------------------
Ralf Nolden

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org
Version: GnuPG v1.2.1 (GNU/Linux)


Reply to: