-1 on merging kio-extras into kio. For frameworks we need to keep an eye on the dependency tree and kio-extras has quite a number of additional dependencies (phonon, samba, libssh, mtp, kdsoap etc) and the features that kio-extras provides are usually. I don't want my app to depend on all of that just to be able to use ApplicationLauncherJob et al

increases work for KDE's release team and distro packagers to have more packages to tar, package, update, manage, etc

I'd expect the release process to be sufficiently automated that this is not an issue

In T13631#240200, @nicolasfella wrote:

-1 on merging kio-extras into kio. For frameworks we need to keep an eye on the dependency tree and kio-extras has quite a number of additional dependencies (phonon, samba, libssh, mtp, kdsoap etc) and the features that kio-extras provides are usually. I don't want my app to depend on all of that just to be able to use ApplicationLauncherJob et al

I remember hearing about a proposal to move ApplicationLauncherJob into KService to bypass just that issue. Alternatively, do you see a better place to merge kio-etras?

In T13631#240230, @ngraham wrote:

I remember hearing about a proposal to move ApplicationLauncherJob into KService to bypass just that issue.

That's T13590.

Alternatively, do you see a better place to merge kio-etras?

No, but I don't see a pressing need to merge it anywhere either

Distros can fail to pre-install them in their Plasma packaging, leading to users missing content and having a sub-optimal user experience

Sure, distros make mistakes too, but that kind of mistake is easy to address downstream

Users of DIY distros like Arch or Debian can fail to install them and wind up missing content and having a sub-optimal user experience

That's the price you needs to pay for using such a distro. You need to think about what to install. Following the logic of why some people prefer this kind of distro one can argue that some people do not install these extra packages on purpose.

Reduces the clarity of the software's status: Is this stuff core functionality or not? On the one hand, it's hosted on KDE infrastructure and tracked on KDE's Bugzilla. But on the other hand, it's possible to not install it

How is merging it clarifying anything? Right now the status is pretty clear IMO: stuff in *-extras is not core functionality but provides additional features that one may or may not want to use

On the flip side, I see no major advantages to having stuff split into these extra repos.

For a framework like KIO I made my point above. A similar point can be made for Plasma too. Plasma is used as a base for various embedded products (Plasma Mobile, Mycroft, Plasma Bigscreen, kiosk deployments. I've also seen kwin used as a standalone window manager in commercial products). For these kinds of projects it is beneficial to be able to deploy a core-only version of our product since stuff like installation size does matter.

Accordingly, I would like to propose that we merge the contents of the "addons/extras/plugins" repos back into their logical parent repos:

Stuff in kdeplasma-addons gets merged into plasma-desktop or plasma-workspace, as appropriate

plasma-desktop I don't reeeeaaaally object, but -1 for plasma-workspace for the reasons above

Stuff in kio-extras and kdegraphics-thumbnailers go into frameworks-kio

-1 for reasons above. Maybe it would make sense to merge kdegraphics-thumbnailers into kio-extras though

The wallpapers in plasma-workspace-wallpapers go into plasma-workspace

Fine with me

The plugins in dolphin-plugins move into dolphin itself

Fine with me

stuff in *-extras is not core functionality but provides additional features that one may or may not want to use

I have seen many bug reports and user frustrations whose root cause was not having these packages installed--whether due to bad distro defaults or not knowing about them when using Arch or Debian. We can bug distros to have better defaults and write better documentation and such, but merging their functionality into other repos eliminates the whole class of bug altogether. That's a win IMO.

For a framework like KIO I made my point above. A similar point can be made for Plasma too. Plasma is used as a base for various embedded products (Plasma Mobile, Mycroft, Plasma Bigscreen, kiosk deployments. I've also seen kwin used as a standalone window manager in commercial products). For these kinds of projects it is beneficial to be able to deploy a core-only version of our product since stuff like installation size does matter.

This argument makes sense to me and it's a legitimate use case I hadn't considered.

An alternative way to support this while improving the defaults could be to have this stuff disable-able at build time in CMake. That way users and distros would get them by default (the common case, AKA Simple by default) while distros and platforms with specialized needs could disable them to save a bit of space (the unusual case, AKA Powerful when needed).

In T13631#240269, @ngraham wrote:

I have seen many bug reports and user frustrations whose root cause was not having these packages installed--whether due to bad distro defaults or not knowing about them when using Arch or Debian. We can bug distros to have better defaults and write better documentation and such, but merging their functionality into other repos eliminates the whole class of bug altogether. That's a win IMO.

Binary distros will just create split binary packages anyway and you end up with the same problem. Source distros or devs building from source will have bigger blobs to build whenever there are changes. Users will always find a way to shoot themselves in the foot, it's part of a learning process.

As a packager, I prefer having split packages when it makes sense. And I would rather see more splitting, e.g. with libkworkspace out of plasma-workspace, rather than the opposite. All of these described packages are non-core - wallpapers are just wallpapers -, and even if our -meta packages pull in all those just as it should be, I don't try to nanny our users into accepting all those extra dependencies. It does not cause me any more release work having these split as they are right now. On the flip side, if you make these changes it will cause work for all the packagers.

I agree that having kdegraphics-thumbnailers outside of kio-extras is hard to find a reason for, but I wouldn't say outright that merging them makes more sense than e.g. moving the thumbnails stuff from kio-extras into kdegraphics-thumbnailers. kio-extras is quite the collection right now.

From me also a -1, mostly because of the dependency tree. Stuff like ffmpeg and Samba have a *huge* dependency tree.

Also, merging the repositories does not guarantee everything is a single package. Packagers are still free to split e.g. kio-extras into multiple packages. I would also advise to do so, to keep runtime dependencies reasonable.

I don't try to nanny our users into accepting all those extra dependencies.

You're a Gentoo packager, right? My concern here is for users who want things to just work out of the box, not users of distros geared towards technical experts. That's a different problem space. :)

If nobody likes this idea, I'll drop it. But that would make me feel sad because I think we'll be chasing down distro- and user-specific dependency issues like these forever. It tarnishes our reputation when a user gets an incomplete Plasma session that doesn't include most of the KRunner runners, can't display thumbnails for images or PDFs, and doesn't have the Picture of the Day wallpaper or the weather widget.

Am I the only one who thinks this is a problem, or do people agree that it's a problem but simply don't like the proposed solution?

I agree with moving the runners, but it is also planned to introduce some new APIs so that the Kate/Konsole profiles runners can be replaced and are provided within the Kate/Konsole apps themselves. For the remaining runners it makes totally sense.

And moving the dolphin-plugins repo inside dolphin makes IMO sense too. Also these version control plugins are not very discoverable, which is really unfortunate.

In T13631#240302, @ngraham wrote:

I don't try to nanny our users into accepting all those extra dependencies.

You're a Gentoo packager, right? My concern here is for users who want things to just work out of the box, not users of distros geared towards technical experts. That's a different problem space. :)

By far not everyone of our users is an expert, and I don't see the numbers to back this up as a huge problem yet. There sure has been the odd forum thread about missing stuff, but through our KDE Wiki it is common knowledge that users are supposed to use the plasma-meta package and that settles it real quick. Is it really beginners who randomly install the minimal plasma-desktop package (if they do, why?) rather than following the distro's Wiki, or is it the tinkerer who doesn't own up to hunting for features manually after going the minimal route? How many distros get it actually wrong, can it be improved by adding RUNTIME infos to cmake? Where are those bug reports you see coming from? Those are the questions before establishing this as a problem we need to fix by lumping repositories together. And that would change it for something like Arch where binary packages are not often being split, but not for others like Debian where the amount of binary packages may not even change except where they pull their sources from.

I am fine with identifying core -runners, -widgets, -thumbnails etc. that should be moved. I don't think that includes stuff like the comic widget (that still requires kross) or dolphin plugins that solely target developers.

dolphin plugins that solely target developers

That also has mountiso and dropbox plugins, these are not just for developers

In T13631#240328, @alex wrote:

dolphin plugins that solely target developers

That also has mountiso and dropbox plugins, these are not just for developers

Yes, that's two out of five.

Yes, that's two out of five.

True, but all of them are disabled by default(which is IMO debatable for the mentioned two). So if we would move them to dolphin most users that don't use them anyways won't be bothered by them.

In T13631#240269, @ngraham wrote:

stuff in *-extras is not core functionality but provides additional features that one may or may not want to use

I have seen many bug reports and user frustrations whose root cause was not having these packages installed--whether due to bad distro defaults or not knowing about them when using Arch or Debian. We can bug distros to have better defaults and write better documentation and such, but merging their functionality into other repos eliminates the whole class of bug altogether. That's a win IMO.

+1, I was just bit by this issue (in my PR) because I did not know about kdegraphics-thumbnailers and it was somehow not installed as part of the KDE task.
It's tempting to say "fix the distros" but there are more than a thousand around, and getting consistent behaviour sounds like trying to herd cats, if it's not done properly upstream.
From my point of view merging kdegraphics-thumbnailers into kio-extras is a good starting point.

For a framework like KIO I made my point above. A similar point can be made for Plasma too. Plasma is used as a base for various embedded products (Plasma Mobile, Mycroft, Plasma Bigscreen, kiosk deployments. I've also seen kwin used as a standalone window manager in commercial products). For these kinds of projects it is beneficial to be able to deploy a core-only version of our product since stuff like installation size does matter.

This argument makes sense to me and it's a legitimate use case I hadn't considered.

An alternative way to support this while improving the defaults could be to have this stuff disable-able at build time in CMake. That way users and distros would get them by default (the common case, AKA Simple by default) while distros and platforms with specialized needs could disable them to save a bit of space (the unusual case, AKA Powerful when needed).

Interesting dilemma. Maybe another solution is to provide minimal packages for these edge cases where package size does matter.
That's the solution for ie, VIM on some BSD's.

TBH this needs looking at much more fine grained case-by-case than what the description suggest. Broadly stating that all plugins should be in the repo that provides the plugin API is oversimplifying things. I'm no fan of these extra repos but there is a use case for them. Albeit an often abused one.

For example: Who needs a slave to view manpages? Most users sure don't. In fact most software doesn't even have reasonable ways to use it. KIO, as standalone framework, doesn't have any use for it. What possible use could have the manpages slave have on Android. Plasma as a whole product doesn't either as it has no viewer for generic slaves. 99% of our applications do not either because they too lack any reason or facility to display random output. AFAIK only Konqueror and KHelpcenter have use of it. So the options are:

(Disclaimer: I do not actually know if KHC uses the slave, but I should hope so ;))

• put it where it's utterly useless to 99% of all uses (KIO) incurring unnecessary dependencies for the entire tree
• or put it in one of the two consumers making the other unnecessarily depend on it
• or put it in a third thing that contains nice to have crap that Konqueror kinda wants to have and KHelpcenter kinda needs to have

I hope we can agree that option 3 is what one would generally go for here. Now maybe that third thing shouldn't be a meta repo for all the extra things where everyone puts stuff they don't know where to put, but perhaps a kio-man repo containing just that. And that is why we are where we are because solving the discoverability problem is hard and it's much easier to throw everything into the communal soup pot instead. This has gotten better over time, we can now tag RUNTIME deps in cmake and that solves like 90% of the problem. To pick up on the split sinetek stumbled over: if kio-extras had a note saying that one definitely also wants ffmpegthumbs for films, kdegraphics-thumbs for pdfs, etc. discovering these other generally useful thumbnailers had only been a grep away (not that the fact that half the thumbnailers are arbitrarily in kio-extras and the others are not makes a whole lot of sense to me anyway).

With all that said folding all of kio-extras into kio is clearly and will not ever have many friends. kio-extras has wildly divergent levels of quality, not to mention that probably half of it even has a very weak user story.

I agree with you that these repos have wildly divergent content, with similarly divergent levels of quality. In my mind that's an example of the problem: it lets us avoid having tough conversations about whether something deserves to exist and where it should be, if it does. It's much easier to just put it in an Extras repo and call it a day.

For your manpage ioslave example, I think it would make the most sense to package it separately in its own repo, and have Konqueror and KHelpCenter depend on it. That way it will always get pulled in as a dependency when needed, and people who don't use Konqueror or KHelpCenter won't have to have it.

However thumbnailers for example are in a different league: they are broadly useful to practically everyone--or at least, a much larger fraction of the people to whom the manpage ioslave is useful. :) Personally I think they deserve to be treated as first-class citizens and shipped by default, either in KIO itself, or in a dedicated thumbnailers repo that KIO or GUI apps would have a dependency on.

As long as we accept the concept of the grab-bag extras/addons/plugins repo, there will always be the temptation to put stuff in them and avoid the more difficult work of either extra packaging and dependency tracking, or committing to something being a part of the core experience with commensurate code quality.

Hi, I've recently created this with proposal of merging dolphin-plugins to dolphin. What's the status of this?

@sitter

Pulling e.g. the thumbnailers into kio is a complete no-no. They have all kinds of third-party dependencies.

If you want thumbnailers *at runtime*, add a *runtime dependency*. Making these a compile-time dependency for KIO core won't enforce runtime availability.

If you want extra thumbnailers (i.e. ones that have comparatively large dependency chains) to be discoverable, make these discoverable, e.g. in the preview configuration dialog. appdata/metainfo also has the notion of plugins.

In T13631#250934, @soredake wrote:

Hi, I've recently created this with proposal of merging dolphin-plugins to dolphin. What's the status of this?

How would I know? 😅

As we can gleam from the comments nobody retracted their opposition and the proposal wasn't refined either = continues to be as opposed as ever.

I don't see what wrong with merging dolphin-plugins into main dolphin, git integration is useful for devs, dropbox integration is useful for all, "mount iso" should be available by default too, like in windows/macos.

@soredake - You are barking up the wrong tree. You want packaging changes, not source changes, i.e. install the plugins as soon as dolphin is installed. Talk to your distro maintainers to make this happen.

I don't think debian maintaners will do this, https://invent.kde.org/sdk/dolphin-plugins is separate repository, and i want dolphin-plugins be merged in dolphin, so all distros will benefit from this.

You want packaging changes, not source changes

That's kind of the problem; some distros don't do the right thing here, and contacting every distro is not really feasible. Yes, you can say, "well X distro does it right, people should just use X distro", but that's not a realistic perspective given that we encourage our software to be widely packaged. The perspective I'm coming from is that of trying to improve the user experience for all of our users, not just those who choose distros that are well-packaged. I see the fact that our software can be mis-packaged as a problem in the first place.

Distributions do split stuff as they feel like, even when we put everything into one source. e.g. on debian kdeplasma-addons is split into 7 binary packages, I am not sure why, meanwhile kio-extras is split in two (with thumbnailers and slaves being in the same .deb, mind you).
Being able to mispackage is a fact of life in free software. The only real way to stop that is to start embracing flatpaks and snaps.

Meanwhile we, KDE, are collectively doing a bad job at codifying runtime relationships in general. Here's dolphin's cmake summary

-- The following OPTIONAL packages have been found:

 * KF5Sonnet (required version >= 5.80.0)
 * KUserFeedback (required version >= 1.0.0)
   Used for submission of telemetry data
 * KF5Activities (required version >= 5.77.0), KActivities libraries, <https://www.kde.org>
   For tracking which folders are frequently accessed on a Plasma desktop
 * PackageKitQt5, Software Manager integration
   Used in the service menu installer
 * KF5Baloo (required version >= 5.77.0), Baloo Core libraries, <https://www.kde.org>
   For adding desktop-wide search and tagging support to dolphin
 * KF5Service (required version >= 5.80.0)
 * KF5ItemViews (required version >= 5.80.0)
 * KF5JobWidgets (required version >= 5.80.0)
 * KF5Auth (required version >= 5.80.0)
 * KF5Codecs (required version >= 5.80.0)
 * KF5WidgetsAddons (required version >= 5.80.0)
 * KF5ConfigWidgets (required version >= 5.80.0)
 * KF5XmlGui (required version >= 5.80.0)
 * KF5BalooWidgets (required version >= 19.07.70), Baloos Widgets, <https://www.kde.org>
 * KF5FileMetaData (required version >= 5.77.0), <https://projects.kde.org/kfilemetadata>
   For accessing file metadata labels

-- The following RECOMMENDED packages have been found:

 * Gem:test-unit, Ruby gem 'test-unit' required for testing of servicemenu helpers.

-- The following REQUIRED packages have been found:

 * ECM (required version >= 5.77.0)
 * Qt5Gui
 * KF5DocTools (required version >= 5.77.0)
 * KF5Init (required version >= 5.77.0)
 * KF5KCMUtils (required version >= 5.77.0)
 * KF5NewStuff (required version >= 5.77.0)
 * KF5DBusAddons (required version >= 5.77.0)
 * KF5Parts (required version >= 5.77.0)
 * KF5IconThemes (required version >= 5.77.0)
 * Gettext
 * KF5I18n (required version >= 5.80.0)
 * KF5TextWidgets (required version >= 5.77.0)
 * KF5Notifications (required version >= 5.77.0)
 * KF5Crash (required version >= 5.77.0)
 * Qt5 (required version >= 5.15)
 * KF5 (required version >= 5.77.0)
 * Phonon4Qt5
 * KF5Completion (required version >= 5.80.0)
 * KF5Solid (required version >= 5.80.0)
 * KF5Config (required version >= 5.80.0)
 * Qt5Widgets (required version >= 5.14.0)
 * KF5WindowSystem (required version >= 5.80.0)
 * Qt5Network (required version >= 5.14.0)
 * Qt5Concurrent (required version >= 5.14.0)
 * Qt5DBus (required version >= 5.14.0)
 * KF5KIO (required version >= 5.71.0)
 * KF5CoreAddons (required version >= 5.71.0)
 * Qt5Core (required version >= 5.14.0)
 * Qt5Test

No mention of the plugins, nor of kio-extras. Looking at this from the point of view that we are essentially distributing source code, then we aren't even telling the user what to install to get a good experience with dolphin. That is even ignoring the fact, that per your argument 3/4th of the optional deps there shouldn't be optional because building without them degrades UX. (not that I'm disagreeing with the argument, and in fact I hate optional deps with a fierce passion so I'd even +1 on that :P)

The only real way to stop that is to start embracing flatpaks and snaps.

I would like to, but having two dolphins installed is not something i want.

I hate optional deps

I like fedora for their package manager that installs recommended packages by default, but unfortunately dolphin-plugins is not even recommended in dolphin spec in fedora.

In T13631#251183, @ngraham wrote:

You want packaging changes, not source changes

That's kind of the problem; some distros don't do the right thing here, and contacting every distro is not really feasible. Yes, you can say, "well X distro does it right, people should just use X distro", but that's not a realistic perspective given that we encourage our software to be widely packaged. The perspective I'm coming from is that of trying to improve the user experience for all of our users, not just those who choose distros that are well-packaged. I see the fact that our software can be mis-packaged as a problem in the first place.

We can encourage our users to improve the packaging on "their" distro. Everyone can write a bug report.

Putting everything into on repository won't stop any distribution from bad packaging. It will hurt any distribution which does a good job at packaging (It will make it harder to split up packages in a sensible way. It will make building harder due extra dependencies early in the build chain). It will also have bad effects on CI.

The best way to help distributions to do a good job with packaging is to add the relevant information to any plugins. Metainfo is the de-facto format for this. As it is human-readable, it can also be used for packaging schemes where it is not integrated. RPM and DEB both have "Enhances:" reverse dependencies to be used by plugins.

It will make building harder due extra dependencies early in the build chain

Not in case of dolphin-plugins, which does not have extra deps.

I guess the path forward is to do a better job of specifying these relationships in CMake, then.

fwiw I'm not even against merging dolphin and dolphin-plugins in particular, but I'm strictly against doing it for kio/kio-extras

Are there any movements of merging dolphin/dolphin-plugins?

but I'm strictly against doing it for kio/kio-extras

Agreed, in frameworks we should keep the dependencies in mind

Are there any movements of merging dolphin/dolphin-plugins?

@elvisangelaccio Thoughts?

@elvisangelaccio