[arch-dev-public] Migration to QT4
Hi all, as I mentioned some time ago I want to move qt4 to [extra] soon. I am quite busy right now; so there is some delay but I am still working on this. Before committing my changes to [testing] I want to discuss the upgrade path again. (because it will be some work to revert this changes if it was a bad idea after all) qt and qt-docs will be updated to version 4. They will replace the packages from community and provide qt4 as well. Like the community package they will be installed into /usr instead of /opt. We do not need any script in /etc/profile.d then. Version 3 of qt will be packaged as qt3 and qt3-docs. It will stay in /opt and still will have a profile script; but it will be disabled per default. All packages directly depending on qt version 3 will be repackaged to depend on qt3. The PKGBUILD have to source the profile. Packages like KDE and others depending on kdelibs do not need to be rebuilt. Pierre -- archlinux.de
On Sun, 4 Nov 2007, Pierre Schmitz wrote:
Hi all,
as I mentioned some time ago I want to move qt4 to [extra] soon. I am quite busy right now; so there is some delay but I am still working on this.
Before committing my changes to [testing] I want to discuss the upgrade path again. (because it will be some work to revert this changes if it was a bad idea after all)
qt and qt-docs will be updated to version 4. They will replace the packages from community and provide qt4 as well. Like the community package they will be installed into /usr instead of /opt. We do not need any script in /etc/profile.d then.
Version 3 of qt will be packaged as qt3 and qt3-docs. It will stay in /opt and still will have a profile script; but it will be disabled per default. All packages directly depending on qt version 3 will be repackaged to depend on qt3. The PKGBUILD have to source the profile.
Packages like KDE and others depending on kdelibs do not need to be rebuilt.
Pierre
In the previous discussions, it was suggested to split qt4 into 3 packages: qt4core qt4-x11 and qt4qt3support Is it still the case? From the above upgrade path, it doesn't seem so. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
2007/11/6, Eric Belanger <belanger@astro.umontreal.ca>:
On Sun, 4 Nov 2007, Pierre Schmitz wrote:
Hi all,
as I mentioned some time ago I want to move qt4 to [extra] soon. I am quite busy right now; so there is some delay but I am still working on this.
Before committing my changes to [testing] I want to discuss the upgrade path again. (because it will be some work to revert this changes if it was a bad idea after all)
qt and qt-docs will be updated to version 4. They will replace the packages from community and provide qt4 as well. Like the community package they will be installed into /usr instead of /opt. We do not need any script in /etc/profile.d then.
Version 3 of qt will be packaged as qt3 and qt3-docs. It will stay in /opt and still will have a profile script; but it will be disabled per default. All packages directly depending on qt version 3 will be repackaged to depend on qt3. The PKGBUILD have to source the profile.
Packages like KDE and others depending on kdelibs do not need to be rebuilt.
Pierre
In the previous discussions, it was suggested to split qt4 into 3 packages: qt4core qt4-x11 and qt4qt3support Is it still the case? From the above upgrade path, it doesn't seem so.
The splitup is a must. There are already some packages that require Qt Core but not Qt GUI. -- Roman Kyrylych (Роман Кирилич)
On 06/11/2007, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
The splitup is a must. There are already some packages that require Qt Core but not Qt GUI.
To paraphrase Pierre: as far as I can see there is no support to build these pkgs separately other than by doing the dirtiest set of hacks you have ever seen.
2007/11/12, Phil Dillon-Thiselton <dibblethewrecker@gmail.com>:
On 06/11/2007, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
The splitup is a must. There are already some packages that require Qt Core but not Qt GUI.
To paraphrase Pierre: as far as I can see there is no support to build these pkgs separately other than by doing the dirtiest set of hacks you have ever seen.
Anyway I cannot find any package that requires only qt4core in AUR now. :-/ Though I'm 100% sure I saw it. As Pierre said - the splitup can be done later if really needed. -- Roman Kyrylych (Роман Кирилич)
Hi, I just finished uploading all qt related packages into [testing] (x86_64 and i686). As allready mentioned the following changes were made: qt updated to version 4; replaces and provides qt4 from [community] qt-doc " qt3 old qt package; /etc/profile.d/qt.sh was renamed to /etc/profile.d/qt3.sh and disabled by default qt3-doc old qt-doc package In addition to this the following packages had to be rebuilt to switch to the new qt3 dependency. If you are the maintainer of such a package please check my changes. kdelibs arts dbus-qt3 qca qca-tls qscintilla poppler-qt lyx opera qgit wpa_supplicant_gui pyqt libfwbuilder qwt qwtplot3d eric oprofile valkyrie dssi hydrogen muse qjackctl mythtv avahi fwbuilder scribus licq twinkle-kdefree twinkle valknut djvulibre doxygen hpoj lineak_xosdplugin xdrawchem pinentry netgo spassgen qtparted gtk-qt-engine speedcrunch <- no source available see http://bugs.archlinux.org/task/8600 If you build a package which directly or indirectly (e.g. via kdelibs) depends on qt3, you have to add ". /etc/profile.d/qt3.sh" to the build() function to set qt3's environment variables. qt (version 4) is the default qt now. In addition to this I added a psi as the first package in [extra] using qt-4. Next steps: * update all packages which require qt-4 for their current version * review the qt-4 package: * should we add/remove congigure options? * What are those kde-copy patches? * 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 * 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 * make sure that all qt3 packages still work * notify tur-users to update [community] packages according to this chagne * move everything to [extra] after at least one week of testing Pierre PS: If you use qtcurve you'll find compatible packages at http://www.archlinux.de/~pierre/packages -- archlinux.de
i've put updatesync-many: Updating entry: qsynth updatesync-many: Updating entry: stellarium to testing64 (testing32 will follow when have some time at home) this are pkgs that newly depend on qt4 and can be moved out of testing at the same time qt4 goes official. there will be some more of such pkgs - i will post them in reply to this email, to keep track. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Am Dienstag, 13. November 2007 13:32:23 schrieb Damir Perisa:
i've put
updatesync-many: Updating entry: qsynth updatesync-many: Updating entry: stellarium
to testing64 (testing32 will follow when have some time at home)
this are pkgs that newly depend on qt4 and can be moved out of testing at the same time qt4 goes official.
there will be some more of such pkgs - i will post them in reply to this email, to keep track.
- D
I am not sure how many package are in our queue for being updated to use qt-4. Perhaps I'll create a Task in Flyspray to keep track of everything. Pierre -- http://www.archlinux.de
Hi Pierre, what about PyQT4? i realised you rebuilt the pyqt we have (still in version 3.x) against qt3 and put it in testing. shouldn't it be renamed to pyqt3 and pyqt updated to version 4.y? i realised it while updating qwt and qwtplot3d to built against qt4 and move them from /opt/qt to /usr (qtiplot needs update/rebuild but it depends newly on qt4 AND pyqt4 now). don't touch this pkgs (qtiplot build system is quite messy), i will proceed as soon as pyqt4 is ready. what is your opinion on pyqt4? do we update pyqt and make a new pyqt3 pkg? or are we making a pyqt4 pkg and leave the pyqt to 3.x? have to go, read you later, damir -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Damir Perisa Verzonden: dinsdag 13 november 2007 14:51 Aan: arch-dev-public@archlinux.org Onderwerp: [arch-dev-public] PyQT4?
Hi Pierre,
what about PyQT4?
i realised you rebuilt the pyqt we have (still in version 3.x) against qt3 and put it in testing.
shouldn't it be renamed to pyqt3 and pyqt updated to version 4.y?
i realised it while updating qwt and qwtplot3d to built against qt4 and move them from /opt/qt to /usr (qtiplot needs update/rebuild but it depends newly on qt4 AND pyqt4 now). don't touch this pkgs (qtiplot build system is quite messy), i will proceed as soon as pyqt4 is ready.
what is your opinion on pyqt4? do we update pyqt and make a new pyqt3 pkg? or are we making a pyqt4 pkg and leave the pyqt to 3.x?
Same issue with some bindings like poppler. We have a poppler-qt package, which is qt3. We don't have a poppler-qt4 package because qt4 wasn't official yet.
Am Dienstag, 13. November 2007 14:51:14 schrieb Damir Perisa:
what is your opinion on pyqt4? do we update pyqt and make a new pyqt3 pkg? or are we making a pyqt4 pkg and leave the pyqt to 3.x?
Introducing a pyt4 package would be really confusing. So we should update those packages to qt4 and introduce qt3 packages with the 3 postfix. I'll see how many packages depend on pyqt, poppler etc.. -- http://www.archlinux.de
Tuesday 13 November 2007, Pierre Schmitz wrote: | Am Dienstag, 13. November 2007 14:51:14 schrieb Damir Perisa: | > what is your opinion on pyqt4? | > do we update pyqt and make a new pyqt3 pkg? | > or are we making a pyqt4 pkg and leave the pyqt to 3.x? | | Introducing a pyt4 package would be really confusing. So we should | update those packages to qt4 and introduce qt3 packages with the 3 | postfix. | | I'll see how many packages depend on pyqt, poppler etc.. any schedule for pyqt? this weekend i'm probably offline because of a dancing festival (tango). - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Am Donnerstag, 15. November 2007 02:35:26 schrieb Damir Perisa:
any schedule for pyqt? this weekend i'm probably offline because of a dancing festival (tango).
OK, this does not seem to be straight forward. So I need some feedback from the maintainers of the following packages. (They somehow depend on each other) poppler-qt I wanted to introduce the old package as poppler-qt3 and update poppler-qt to use qt-4. However: it does not compile against qt-4 when the bindings-patch is applied. pyqt should be updated to 4.3.1. The old version would be renamed to pyqt3 for consistency. The problem: it depends on qscintilla which uses qt3 atm. qscintilla This package confuses me. The provide a QScintilla-1.73-gpl-2.1.tar.gz and QScintilla-1.71-gpl-1.7.1.tar.gz (which we currently use). According to their homepage "QScintilla v2 supports both Qt v3 and Qt v4". Is there an easy way to provide two non conflicting packages for qt3 and qt-4? Is it usefull to introduce a common packge which includes those files which are shared by the qt3 andqt-4 version? Pierre -- http://www.archlinux.de
On Sat, 17 Nov 2007, Pierre Schmitz wrote:
Am Donnerstag, 15. November 2007 02:35:26 schrieb Damir Perisa:
any schedule for pyqt? this weekend i'm probably offline because of a dancing festival (tango).
OK, this does not seem to be straight forward. So I need some feedback from the maintainers of the following packages. (They somehow depend on each other)
qscintilla This package confuses me. The provide a QScintilla-1.73-gpl-2.1.tar.gz and QScintilla-1.71-gpl-1.7.1.tar.gz (which we currently use). According to their homepage "QScintilla v2 supports both Qt v3 and Qt v4". Is there an easy way to provide two non conflicting packages for qt3 and qt-4? Is it usefull to introduce a common packge which includes those files which are shared by the qt3 andqt-4 version?
The 2 qscintilla packages won't conflict with each other. The current qscintilla package in extra installs in /opt/qt and the qscintilla2 package in community installs in /usr. Even if we decide to have both packages install in /usr, they won't conflict as the filenames and directory structure is different. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Am Samstag, 17. November 2007 21:56:52 schrieb Eric Belanger:
The 2 qscintilla packages won't conflict with each other. The current qscintilla package in extra installs in /opt/qt and the qscintilla2 package in community installs in /usr. Even if we decide to have both packages install in /usr, they won't conflict as the filenames and directory structure is different.
Allright. Let's just forget my previous mail. It does not seem to be my day. :-) There are no real problems with the mentioned packages. I will upload the stuff in a few moments. -- http://www.archlinux.de
Hello, within a second step I updated some libs depending on qt to their new qt-4 versions. This requires the introduction of some foo-qt3 packages. The following packages were updated to qt-4 versions: qsintilla pyqt poppler-qt "new" packages supporting old qt3: qscintilla-qt3 pyqt3 poppler-qt3 packages which needed updated dependencies: kdebindings eric hplip kdegraphics @Damir: I did not touch qtiplot. QCA is a similar candidate but version 2.0.0 does not compile for me. I'll have to look into this. If anyone know anything about how to solve this, please let me know. But only psi (2.0) and kdenetwork (1.0) uses qca. PS: Currently only x86_64 packages are available in [testing]. -- http://www.archlinux.de
Sunday 18 November 2007, Pierre Schmitz wrote: | Hello, | | within a second step I updated some libs depending on qt to their | new qt-4 versions. This requires the introduction of some foo-qt3 | packages. | | The following packages were updated to qt-4 versions: | qsintilla | pyqt | poppler-qt | | "new" packages supporting old qt3: | qscintilla-qt3 | pyqt3 | poppler-qt3 | | packages which needed updated dependencies: | kdebindings | eric | hplip | kdegraphics thanx! | @Damir: I did not touch qtiplot. i'll have a look at it tomorrow. | PS: Currently only x86_64 packages are available in [testing]. ok, i'll synch tomorrow morning with testing and get pyqt=4.3.1 and then work with it. thanx for your work! best regards, Damir -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Am Sonntag, 18. November 2007 00:28:48 schrieb Pierre Schmitz:
PS: Currently only x86_64 packages are available in [testing].
i686 is up to date now, too. -- http://www.archlinux.de
participants (6)
-
Damir Perisa
-
Eric Belanger
-
Jan de Groot
-
Phil Dillon-Thiselton
-
Pierre Schmitz
-
Roman Kyrylych