@dfaure I just realized that this could cause dependency wise issues for KIO. According to the metainfo.yaml currently kcmutils and kio are tier3.

What would be the issue? A tier3 framework can depend on another tier3 framework.
And KCMUtils doesn't depend on KIO, so KIO can depend on KCMUtils.
It's however a bit "sad" to add more dependencies to KIO, people tend to find it has too many already.....

What would be the issue? A tier3 framework can depend on another tier3 framework.

Makes sense, I was not sure if there are any plans to change the tier of at least certain party of KIO (just like KNewStuff core is a tier2 framework).

It's however a bit "sad" to add more dependencies to KIO, people tend to find it has too many already.....

Do you have other ideas or do you disagree with the task?

Actually, if KCMUtils is trimmed down, maybe its own dependencies (and tier?) can be trimmed down? Then it would be even less of a problem for KIO to depend on it...

https://phabricator.kde.org/T14367
And some smaller cleanup https://invent.kde.org/frameworks/kcmutils/-/merge_requests/43

But then we still have the Kdeclarative dependency, not sure if its's tier can be trimmed down with all of planned cleanups.

As things are right now KCMUtils depends on KDeclarative, which depends on KIO, so if we make KIO depend on KCMUtils we have a loop.

There are probably multiple ways we can break that loop, one of them being removing the KCMs from KIO (as discussed in T12285)

Especially with the current trend of porting KCMs to QML, they should really move out of KIO then...

https://invent.kde.org/frameworks/kcmutils/-/merge_requests/121