Summary: | x11-libs/qscintilla & dev-python/qscintilla-python: add support for Qt5/PyQt5 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Helmut Jarausch <jarausch> |
Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | andrej.gelenberg, arnaudv6, asturm, egorov_egor, Ikonta, jarausch, joakim.nohlgard, O01eg, python, tomboy64, yamadharma |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 577850, 600482 | ||
Attachments: |
qscintilla-2.9-r1.ebuild
qt5_libname.patch qt5_mkspecs_path.patch qscintilla-python-2.9-r1.ebuild qsci_link.patch qt5_includes.patch qt5_python_libname.patch qscintilla-python-2.9-r1.ebuild qscintilla-multibuild.patch |
Description
Helmut Jarausch
2015-02-28 09:19:47 UTC
Where did you find eric-6? It's not in tree. QScintilla2 *is* in tree. What's missing is the PyQt5 wrapper of qscintilla-python, i.e. USE=qt5 for qscintilla-python Created attachment 402688 [details] qscintilla-2.9-r1.ebuild Added the qt5 USE flag to the qscintilla ebuild. I used the same procedures and some patches from the Debian qscintilla2 source package https://packages.debian.org/jessie/python3-pyqt5.qsci Created attachment 402690 [details, diff]
qt5_libname.patch
Created attachment 402692 [details, diff]
qt5_mkspecs_path.patch
Created attachment 402694 [details]
qscintilla-python-2.9-r1.ebuild
Created attachment 402696 [details, diff]
qsci_link.patch
Created attachment 402698 [details, diff]
qt5_includes.patch
Created attachment 402700 [details, diff]
qt5_python_libname.patch
qsci_link.patch qt5_includes.patch qt5_python_libname.patch belong with qscintilla-python-2.9-r1.ebuild qt5_libname.patch qt5_mkspecs_path.patch belong with qscintilla-2.9-r1.ebuild Created attachment 402706 [details]
qscintilla-python-2.9-r1.ebuild
Updated ebuild with some more dependencies
This is going to become a maintenance nightmare if upstream isn't interested (as it seems) in supporting co-installability of qt4 and qt5 versions. As long as Debian is handling co-installability in their package builds it should be quite straightforward to reuse their patches. Yeah true that, both Debian and Fedora support co-installability, so we can keep stealing the patches from them ;) It seems this issue of (not) supporting co-installability of qt4 and qt5 versions upstream has a common thread or theme with others packages. vlc also (In reply to Ian Delaney from comment #14) > It seems this issue of (not) supporting co-installability of qt4 and qt5 > versions upstream has a common thread or theme with others packages. vlc also vlc is an application, it wouldn't make sense to install both a qt4 and a qt5 version... (In reply to Davide Pesavento from comment #15) > (In reply to Ian Delaney from comment #14) > > It seems this issue of (not) supporting co-installability of qt4 and qt5 > > versions upstream has a common thread or theme with others packages. vlc also > > vlc is an application, it wouldn't make sense to install both a qt4 and a > qt5 version... He means VLC doesn't provide for proper detection of parallel installed Qt4 and Qt5. And how is that relevant to this bug? *** Bug 559174 has been marked as a duplicate of this bug. *** Following closely so I can emerge Juffed built against Qt5 (In reply to Ian Delaney from comment #14) > It seems this issue of (not) supporting co-installability of qt4 and qt5 > versions upstream has a common thread or theme with others packages. vlc also I also think [at least] x11-libs/qscintilla needs in support of Qt slots. Created attachment 429376 [details, diff]
qscintilla-multibuild.patch
Attached diff introduces USE="qt4 qt5" to qscintilla using multibuild.
There isn't a disk file collision without any patches (/usr/lib64/libqscintilla2.so and /usr/lib64/qt4/libqscintilla2.so), but I haven't tested revdeps yet to see if they pick it up by accident.
(In reply to Michael Palimaka (kensington) from comment #21) > Created attachment 429376 [details, diff] [details, diff] > qscintilla-multibuild.patch > > Attached diff introduces USE="qt4 qt5" to qscintilla using multibuild. > > There isn't a disk file collision without any patches > (/usr/lib64/libqscintilla2.so and /usr/lib64/qt4/libqscintilla2.so), but I > haven't tested revdeps yet to see if they pick it up by accident. And qscintilla-python immediately links to the qt5 version. I would generally be against any coinstallability solution that requires patching of revdeps. (In reply to Michael Palimaka (kensington) from comment #22) > I would generally be against any coinstallability solution that requires > patching of revdeps. I would tend to agree. Although note that the two libs have the same soname, which means that we'd still have to rename one of the two (probably the qt5 one) even if they don't collide on the filesystem. Anyway, can we do REQUIRED_USE="^^ ( qt4 qt5 )" instead? (In reply to Davide Pesavento from comment #23) > (In reply to Michael Palimaka (kensington) from comment #22) > > I would generally be against any coinstallability solution that requires > > patching of revdeps. > > I would tend to agree. Although note that the two libs have the same soname, > which means that we'd still have to rename one of the two (probably the qt5 > one) even if they don't collide on the filesystem. If it wasn't clear, the consequence of this lib renaming is that reverse deps should continue to work unpatched and link against the non-renamed (i.e. qt4) library. Only reverse deps interested in supporting qt5 would have to be patched. @kensington, any further thoughts? (In reply to Davide Pesavento from comment #23) > Anyway, can we do REQUIRED_USE="^^ ( qt4 qt5 )" instead? IMO this is our only option. (In reply to Michael Palimaka (kensington) from comment #26) > (In reply to Davide Pesavento from comment #23) > > Anyway, can we do REQUIRED_USE="^^ ( qt4 qt5 )" instead? > > IMO this is our only option. just to clarify, you wouldn't support renaming the qt5 version of the library then (like debian and fedora are doing)? (In reply to Davide Pesavento from comment #27) > (In reply to Michael Palimaka (kensington) from comment #26) > > (In reply to Davide Pesavento from comment #23) > > > Anyway, can we do REQUIRED_USE="^^ ( qt4 qt5 )" instead? > > > > IMO this is our only option. > > just to clarify, you wouldn't support renaming the qt5 version of the > library then (like debian and fedora are doing)? If this requires any revdep patching I believe it's a bad idea, but I don't care enough to try and block that from happening or something. qscintilla-2.9.3-r2 can be built against Qt5: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5445db343d15bf741f107fc6e65112f4696ecc82 (In reply to Joakim Gebart Nohlgård from comment #10) > Created attachment 402706 [details] > qscintilla-python-2.9-r1.ebuild > > Updated ebuild with some more dependencies Hi Joakim. I've tried your patch version for qscintilla-python but it fails here: * python3_5: running run_in_build_dir configuration_qt4 /usr/bin/python3.5 ../configure.py --qmake=/usr/lib64/qt4/bin/qmake --destdir=/usr/lib64/python3.5/site-packages/PyQt4 --sip-incdir=/usr/include/python3.5m --pyqt=PyQt4 Error: Qsci/qsciglobal.h could not be found in /usr/include/qt4. If QScintilla is installed then use the --qsci-incdir argument to explicitly specify the correct directory. What am I missing? Many thanks for a hint, Helmut qscintilla-python has Qt5/PyQt5 support too now. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=94c379bcbe5c40707197f209da31547e4e3702eb |