Is udisks really needed for kde-frameworks/solid?

[mi_unixbird]

What kept me from upgrading to KDE5 applications for a long time was that at least on Gentoo it would pull in consolekit, dconf, policykit, udisks and a bunch of other things. I've been getting conflicting messages about whether or not that's all needed from both Gentoo devs and upstream KDE contributors. I've now localized this to what is seemingly one line in that kde-frameworks/solid depends on udisks.

I've since made a local ebuild inside a local overlay which swaps that with "udisks? ( sys-fs/fs-udisks )" and solid built without udisks on my system and I've upgraded a few KDE applications to KDE5 thusfar and they seem to work thusfar without any hastle.

So is there really any reason that on Gentoo solid needs to hard-depend nonoptionally on udisks or is this an oversight in the ebuild that should be fixed?
_________________
execctl --path exec filectl --current-directory list

[Ant P.]

It's probably more a case of there being so many dependencies the ebuild maintainers couldn't be bothered going through and making them all optional. KDE takes far too long to compile *one* time, testing combinations of USE flags would be impossible.

At least it doesn't sound as bad as the GNOME side of the wall, where unnecessary deps like those really are hardcoded for no good reason...

[mi_unixbird]

Seems to me that it should still be put in ~arch though for some testing. If you don't do this you lose half the benefit of running Gentoo.

I've been running Kate, Dolphin, KSysguard and Konsole for a short day now without any problems without udisks. Maybe I'll run into something though. But being able to do this is sort of the point of Gentoo so not checking for it seems weird.
_________________
execctl --path exec filectl --current-directory list

[Chiitoo]

These things are more or less the reason why I'm not using “KDEKFP5”.

I first gave it a go ages, if not months ago, and when I tried to strip this stuff off, it didn't seem so simple because everything would trigger a failure at configure time already if they were missing, meaning some patching would have been required. Perhaps it's time to give it a go again, seeing your results with the solid ebuild. ^^

The people working on these on Gentoo are very open to making things optional, but I believe it's not something they go out of their way to test and make happen. I'm horrible at getting things done (and got lots of other stuff waiting), so I haven't really got to it yet either... one day though! One day...

Thanks for sharing your experiences on this!
_________________
Kindest of regardses.

[asturm]

If upstream declares it required at runtime, then Gentoo won't omit it from dependencies. Also, there is still no proper way for optional runtime deps in portage.

[mi_unixbird]

[asturm]

That's not upstream, that's linuxfromscratch. I don't really know the current stance of upstream, but I do remember a big discussion in KDE4 times on the matter.

EDIT: When I look at the source, there seems to be a switch on the basis of UDEV found for building that and the UDISKS backend. Not known is whether affected depending packages actually have runtime checks for the (non-)availability of those, though.

[The Doctor]

You can hack together your own ebuild to see if omitting it causes any problems. That is the best part about Gentoo. You are free to experiment. Just keep in mind that if it breaks you get to keep the pieces.

I did this for a while on KDE4. I was completely *kit-less and u[power/disk]-less. I had to hack a few e-builds, but it worked. Completely unsupported of course.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[mi_unixbird]