The qt-gui ebuild installs both a designer and linguist GUI application which some users may not want installed on their system by default since it appears in the main menu by default. These applications are not essential to an average user which wants to use the QT libraries. I propose adding a "dev" USE flag which if enabled will build these applications and create their associated .desktop entries, otherwise they will not be installed. The libraries, of course, which are actual dependences should still be installed. Reproducible: Always Steps to Reproduce: 1. emerging x11-libs/qt-gui Actual Results: Installs both designer and linguist applications which are unwanted. Expected Results: Designer and linguist applications are not installed.
Upstream modularization of Qt is a goal for 4.8 (http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/). They plan to separate the tools from qt kernel libraries and we will probably follow them as soon as they finalize their decision.
(In reply to comment #1) > Upstream modularization of Qt is a goal for 4.8 > (http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/). They plan to > separate the tools from qt kernel libraries and we will probably follow them as > soon as they finalize their decision. Hmm. That might take a while. How do other distributions handle this? (I know, e.g., that Kubuntu, doesn't include these by default.) Do they just not include the binaries built?
dev useflag in qt-gui sounds bad. It's not very straightforward and intuitive. There are no ebuilds in the whole Portage tree using a flag like this or similar. The natural solution would be to extract designer and linguist into separate ebuilds. This would however create additional mess, right now for people using these tools and later when Qt 4.8 comes out and its dev tools module differs from our (which is very likely :) ). I'd rather go for keeping the current scheme for a while. The severity of this issue is low and we're several months from 4.8 that is supposed to solve the problem.
Yeah, we should wait for (at least) a technical preview of 4.8 IMHO...
For some obscure reasons bugzilla decided to revert my previous changes... :/
I second the motion of splitting the designer/linguist tools off the main qt install. Do not want or need them.
The upstream modularization has been postponed to Qt5: all the tools reside in a separate qt-tools git repo. So the split should be straightforward to implement in Qt5. On the other hand, I don't think we have the time to fix this for 4.8 :(
(In reply to comment #7) > The upstream modularization has been postponed to Qt5: all the tools reside > in a separate qt-tools git repo. So the split should be straightforward to > implement in Qt5. > On the other hand, I don't think we have the time to fix this for 4.8 :( I'm sorry, but we are not going to implement this for Qt 4.x, the maintenance effort is simply too high.
I'm reconsidering this because it will probably help with the transition to qt5. The current plan is the following: - introduce 2 new packages, let's call them qt-designer and qt-linguist for now - move "tools/linguist/linguist" from qt-gui to qt-linguist - move "tools/designer/src/lib tools/designer/src/components tools/designer/src/designer" from qt-gui to qt-designer - leave "tools/designer/src/uitools" in qt-gui because it's needed by both apps - qt-designer will depend on qt-gui and qt-script (technically qt-script can be made optional but it's too much work for too little gain) - qt-linguist will depend on qt-gui only - move "tools/designer/src/plugins/phononwidgets" from qt-phonon to qt-designer behind USE=phonon - move "tools/designer/src/plugins/qdeclarativeview" from qt-declarative to qt-designer behind USE=qml - move "tools/designer/src/plugins/qwebview" from qt-webkit to qt-designer behind USE=webkit - move "tools/designer/src/plugins/widgets" from qt-qt3support to qt-designer behind USE=qt3support - fix reverse dependencies, e.g. qt-creator - (optional) rdepend or pdepend on qt-assistant to fix bug 448994 Comments? Did I miss anything?
Created attachment 339498 [details] ebuild for qt designer Instead of depending on qt-gui and qt-scripts, I added qt dependencies to the ebuild until it worked. The designer runs, but I didn't test full functionality.
I had to update the qt5-build.eclass too, for supporting qt designer: case ${PN#qt-} in concurrent|core|dbus|gui|network|opengl|printsupport|sql|test|widgets|xm l) EGIT_PROJECT="qtbase" ;; designer) EGIT_PROJECT="qttools" ;; *) EGIT_PROJECT="${PN/-}" ;; esac
Comment on attachment 339498 [details] ebuild for qt designer Don't hijack bug reports please. This one is about qt4's qt-gui ebuild, not about qt5's designer.
Sorry man, I thought this report was the right spot, since you're also talking about qt5. I'll open a new report.
I pushed new split ebuilds for dev-qt/designer and dev-qt/linguist to the qt overlay.
Fully implemented and pushed to portage together with the 4.8.5 bump.