Bug 988808

Don't forget that startkde also needs qtpaths though, which is also in the libqt5-qttools package.

So only splitting out qdbus won't help much, we also need to move qtpaths into a separate package... (which is also needed by libproxy1-config-kde, that also requires libqt5-qttools currently)

What is the status of this bug? I see there are separate repositories for qt-dbus and qt-paths since some time now, but plasma5-workspace still depends on full qt5-qttools. I can confirm that using Plasma works when ignoring this dependency and installing qt-dbus and qt-paths manually.

(In reply to Christoph Feck from comment #2)
> What is the status of this bug?

It is as you say.
qdbus and qtpaths have been split out into separate packages, but plasma5-workspace's dependencies have not been changed yet.

Actually I wanted to do this in time for 42.2, but 42.2's Qt5 packages did/do not incorporate this split so it wouldn't have been possible.
And upto now we also tried to keep the Plasma 5.8 packages in sync between 42.2 and Tumbleweed...

We can probably do the change in KDE:Frameworks5 now that we are at 5.8.95 with 5.9 being released soon.

But then, there's also still libproxy1-config-kde that requires libqt5-qttools currently (it uses qtpaths), as I already mentioned.

(In reply to Wolfgang Bauer from comment #3)

> But then, there's also still libproxy1-config-kde that requires
> libqt5-qttools currently (it uses qtpaths), as I already mentioned.

Maybe (just a remote option) if the bug assignee would have informed the libproxy maintainer about this bug, the dependency could have been adjusted like half a year ago instead of hoping that the libproxy maintainer might accidentally stumble over this bug?

In any case: sr#454966 changes this dep now for libproxy1-config-kde; so this is no longer your 'blocking' argument.

(In reply to Dominique Leuenberger from comment #4)
> In any case: sr#454966 changes this dep now for libproxy1-config-kde; so
> this is no longer your 'blocking' argument.

It was not my "blocking" argument, I just mentioned that this would need to be done too to not pull in the whole libqt5-qttools.
Actually I planned to submit the change myself when plasma5-workspace is adjusted.
And as we didn't do the latter yet, changing libproxy something like half a year ago wouldn't have helped either anyway.

But thank you.

The entire Development section was added by default without giving the option for the user to taboo them.

Not every user knows how to program. We liked the flexibility that openSUSE used to offer before Leap.

Seems people are mostly confused by the chosen RPM group in those packages... they are not Development/* - but rather System/Tools or similar.

It's misleading for users. 

I could not find the packages using Yast. Nothing showed up in the "Patterns". However, I found the library packages that pulled in the qt5-designer.

Hopefully this can be resolved for Leap 42.3.

In openSUSE Leap 42.3
plasma5-workspace still requires libqt5-qttools,
libqt5-qttools requires libQt5Designer5 and libQt5DesignerComponents5.

I would like to be able install plasma5-workspace without installing Qt interface designer and Qt Assistant (both comes with libqt5-qttools). 
I hope this will be fixed for Leap 15.

What situation is in Tumbleweed now?

(In reply to Mindaugas Baranauskas from comment #9)
> In openSUSE Leap 42.3
> plasma5-workspace still requires libqt5-qttools,

qdbus and qtpaths (both used by startkde) are still in libqt5-qttools in Leap 42.3. (Qt5 comes from SLE)
So plasma5-workspace *has* to require it, otherwise you wouldn't even be able to login.

And libproxy-config-kde requires libqt5-qttools too in 42.3, for the very same reasons.

> What situation is in Tumbleweed now?

The change to plasma5-workspace to only require the necessary sub packages is on the way to Tumbleweed:
https://build.opensuse.org/request/show/514538

So it should make it into Leap 15 too...

Wolfgang,

Thank you for resolving this problem. Not everyone is a developer. So rather than looking for library files to taboo during the initial installation. Are we going to see the application name to taboo?

(In reply to Roman Bysh from comment #11)
> Thank you for resolving this problem. Not everyone is a developer. So rather
> than looking for library files to taboo during the initial installation. Are
> we going to see the application name to taboo?

I don't know what you are talking about.

This was an enhancement request to not install the full libqt5-qttools by default (because it also contains development tools that are normally not needed), and it won't be installed by default in the future.

Okay, I glad that it willnot be installed by default. However, in the future if I want to install development packages rather than looking for the library files
will the application name appear in Yast?

I'm used to installing packages by the application name instead of a library file.

(In reply to Roman Bysh from comment #13)
> I'm used to installing packages by the application name instead of a library
> file.

I still don't understand what you are talking about.
You install packages by the package name, not by a "library file".
Unless you use a software center like Plasma discover or gnome-software (zypper has some support for "applications" too).

And I don't see what this has to do with this bug report/enhancement request either...

Never mind. Please disregard my comments.