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@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 kup
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. Pierre -- archlinux.de