- According to bug #523012, /usr/lib64/qt5/plugins and /usr/lib64/qt5/qml are redundant as they are included by default - Plugins should be installed to /usr/lib64/qt5/plugins as of ECM-1.2.0 - QML should be installed to /usr/lib64/qt5/qml as of ECM-1.3.0
pesa says: this should be "....${QT_PLUGIN_PATH:+:}${QT_PLUGIN_PATH}" in any case.
(In reply to Michael Palimaka (kensington) from comment #0) > - According to bug #523012, /usr/lib64/qt5/plugins and /usr/lib64/qt5/qml > are redundant as they are included by default > > - Plugins should be installed to /usr/lib64/qt5/plugins as of ECM-1.2.0 > > - QML should be installed to /usr/lib64/qt5/qml as of ECM-1.3.0 > pesa says: this should be "....${QT_PLUGIN_PATH:+:}${QT_PLUGIN_PATH}" in any > case. Yeah maybe a leftover from the days where some magic was needed to get plasma5 started. Just test it and commit it.(In reply to Michael Palimaka (kensington) from comment #1)
The new env file will consist of just: PATH=/usr/lib64/qt5/bin ROOTPATH=/usr/lib64/qt5/bin CONFIG_PROTECT=/usr/share/config It requires ECM-1.3.0 and all revdeps to be rebuilt, so I suggest we unmask it once the next KF5 and Plasma 5 releases have been made. https://github.com/gentoo/kde/commit/8569d0697352240eacf1d96b017b9dcd80111bac
(In reply to Michael Palimaka (kensington) from comment #3) > The new env file will consist of just: > > PATH=/usr/lib64/qt5/bin Wait what? This env is exported to all shells right? What happens if one has both qt4 and qt5 installed? Which qmake will be used? > It requires [...] all revdeps to be rebuilt Why?
(In reply to Davide Pesavento from comment #4) > (In reply to Michael Palimaka (kensington) from comment #3) > > The new env file will consist of just: > > > > PATH=/usr/lib64/qt5/bin > > Wait what? This env is exported to all shells right? What happens if one has > both qt4 and qt5 installed? Which qmake will be used?\ Yeah, it's exported unconditionally. Qt4 qmake will always be preferred since /usr/bin is higher in PATH priority. > > It requires [...] all revdeps to be rebuilt > > Why? The option to install to the Qt directory was enabled after the last version bump, so anyone who upgraded prior will still have their plugins etc. installed in the old directory.
(In reply to Michael Palimaka (kensington) from comment #5) > (In reply to Davide Pesavento from comment #4) > > (In reply to Michael Palimaka (kensington) from comment #3) > > > The new env file will consist of just: > > > > > > PATH=/usr/lib64/qt5/bin > > > > Wait what? This env is exported to all shells right? What happens if one has > > both qt4 and qt5 installed? Which qmake will be used?\ > Yeah, it's exported unconditionally. Qt4 qmake will always be preferred > since /usr/bin is higher in PATH priority. Is this PATH extension really necessary? What needs it? At build-time or run-time or both? If qt4 binaries can hide qt5 ones at any time because of higher precedence, this sounds fragile to me. (i.e. you'd still need to invoke the tools using the full path to avoid problems on systems where both qt4 and qt5 are installed, but then augmenting PATH becomes pointless) > > > It requires [...] all revdeps to be rebuilt > > > > Why? > The option to install to the Qt directory was enabled after the last version > bump, so anyone who upgraded prior will still have their plugins etc. > installed in the old directory. Oh ok, I thought it was because of the removal of qt5 paths from env.d
(In reply to Davide Pesavento from comment #6) > (In reply to Michael Palimaka (kensington) from comment #5) > > (In reply to Davide Pesavento from comment #4) > > > (In reply to Michael Palimaka (kensington) from comment #3) > > > > The new env file will consist of just: > > > > > > > > PATH=/usr/lib64/qt5/bin > > > > > > Wait what? This env is exported to all shells right? What happens if one has > > > both qt4 and qt5 installed? Which qmake will be used?\ > > Yeah, it's exported unconditionally. Qt4 qmake will always be preferred > > since /usr/bin is higher in PATH priority. > > Is this PATH extension really necessary? What needs it? At build-time or > run-time or both? If qt4 binaries can hide qt5 ones at any time because of > higher precedence, this sounds fragile to me. (i.e. you'd still need to > invoke the tools using the full path to avoid problems on systems where both > qt4 and qt5 are installed, but then augmenting PATH becomes pointless) I believe it was originally added because qtpaths is called at runtime when starting plasma. I guess we could sed in the full path after testing to make sure nothing else breaks. > > > > It requires [...] all revdeps to be rebuilt > > > > > > Why? > > The option to install to the Qt directory was enabled after the last version > > bump, so anyone who upgraded prior will still have their plugins etc. > > installed in the old directory. > > Oh ok, I thought it was because of the removal of qt5 paths from env.d Same thing. If it's still installed to the old directories, it'll break when the plugin/qml path export is removed.
(In reply to Michael Palimaka (kensington) from comment #7) > I believe it was originally added because qtpaths is called at runtime when > starting plasma. I guess we could sed in the full path after testing to make > sure nothing else breaks. > Yes please, avoid touching PATH. Also I guess we could add some helpers or variables (in qmake-utils.eclass?) instead of hardcoding paths in every ebuild... > > > > > It requires [...] all revdeps to be rebuilt > > > > > > > > Why? > > > The option to install to the Qt directory was enabled after the last version > > > bump, so anyone who upgraded prior will still have their plugins etc. > > > installed in the old directory. > > > > Oh ok, I thought it was because of the removal of qt5 paths from env.d > Same thing. If it's still installed to the old directories, it'll break when > the plugin/qml path export is removed. But that's because you removed the *old* install paths, not because you removed the qt5 paths (those should be searched by default regardless of the env var), right? I'm just trying to understand if this thing really works as advertised...
(In reply to Davide Pesavento from comment #8) > Also I guess we could add some helpers or variables (in qmake-utils.eclass?) > instead of hardcoding paths in every ebuild... Couldn't hurt. > But that's because you removed the *old* install paths, not because you > removed the qt5 paths (those should be searched by default regardless of the > env var), right? I'm just trying to understand if this thing really works as > advertised... Right. Once a rebuild/upgrade is done stuff moves from /usr/lib64/plugins -> /usr/lib64/qt5/plugins and the env var is no longer required. I've tested and confirm that stuff in /usr/lib64/qt5/plugins works correctly with no env var exported.
(In reply to Michael Palimaka (kensington) from comment #9) > (In reply to Davide Pesavento from comment #8) > > But that's because you removed the *old* install paths, not because you > > removed the qt5 paths (those should be searched by default regardless of the > > env var), right? I'm just trying to understand if this thing really works as > > advertised... > Right. Once a rebuild/upgrade is done stuff moves from /usr/lib64/plugins -> > /usr/lib64/qt5/plugins and the env var is no longer required. I've tested > and confirm that stuff in /usr/lib64/qt5/plugins works correctly with no env > var exported. Perfect.
Plasma 5.1 is now released so kf-env-3 is now unmasked.
