[arch-dev-public] Migration to QT4

Pierre Schmitz pierre at archlinux.de
Sun Nov 11 17:24:51 EST 2007

Am Sonntag, 11. November 2007 20:34:20 schrieb Vinay Shastry:
> I have read only access to the list. Hence the personal message.
> On Nov 11, 2007 4:14 PM, Pierre Schmitz <pierre at archlinux.de> wrote:
> > Hi,
> >
> > I just finished uploading all qt related packages into [testing] (x86_64
> > and i686).
> Oh my qt4 packages!!! all gone! ;-)
> > <snip>
> > Next steps:
> >         * review the qt-4 package:
> >                 * should we add/remove congigure options?
> IMO, don't think so. I've tried to keep all reasonable options turned on.

Well I have disabled the nas support. I don't see any reason for an additional 
sound server.

> >                 * What are those kde-copy patches?
> ... patches for Qt that haven't been accepted by TrollTech
> yet. All patches in this directory itself shouldn't make qt-copy
> incompatible to official Qt, patches adding new API etc. belong to the
> notsafe/ subdirectory.
> http://websvn.kde.org/trunk/qt-copy/patches/README?revision=734649&view=mar
> Please note that these will need constant updating, as we can expect
> bugs in qt to be fixed now and then.

Thanks for the hint. I should drop a line about this in the next PKGBUILD.

> >                 * do we need to split it into qt, qt-core and
> > qt-qt3support? * currently there is no non-gui package which requires qt,
> > so I decided we can do this later
> Yes, I don't know any either, but it's a good thing to split into
> core, gui and qt3 support. But since pacman/makepkg doesn't have even
> the simplest of splitting functionality, I stopped banging my head on
> this. Would be nice to see if someone solves this "elegantly" ;-)

Currently there is no elegant solution. If QT does not support the splitting 
by providing different configure options (at least for qt3support it does) 
one has to compile the whole stuff three times and remove the garbage.

But as I said. This can be done when needed.

> >         * Do we need to introduce "legacy" packages for libs like
> >                 pyqt, poppler-qt, qscintilla, qca-tls, qca?
> >                 If we only need them for KDE there should be no problem;
> >                 at least after the switch to KDE4
> I think it's a good idea to provide "pkgname-qt3" for qt3 stuff, and
> just "pkgname" for qt4.
> Regarding qt3 package, it can be easily fixed so that the usual
> ./configure scripts work without any need of sourcing the qt3 profile
> from /etc/profile.d, and also calling qmake by full path will work for
> qt3 apps. I can help with that if you are interested.

Well I figured out that some packages compile fine without the profile but 
others don't. I would be happy for any suggestions.

> Also, just 1 week in testing seems too less for this... wanna extend a
> bit just to be safe? :)

Yes, at least one week. I have tested this stuff locally several days or even 
weeks without any problems. The only problems I currently expect are compile 
time issues.

> One more question i have for you is.. why the renaming and trouble of
> rebuilding everything? Why not let Qt 3.X be the "qt" package, and we
> use "qt4" and "kdefoo4" for Qt 4.x and KDE 4.x series packages?

Because it's fun. :-) We normally do not provide several versions of the same 
package. A lot of projects will switch to qt-4 soon anyway. QT3 will be only 
for legacy apps and perhaps we even do not need it anymore in future.

Of course this is has no strong technical motivation.



More information about the arch-dev-public mailing list