| Summary: | kdelibs should not depend on udisks/upower unconditionally | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alec Meyers <alecm_88> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | alecm_88, bugzilla-gentoo, gentoo, luke-jr+gentoobugs, petr.pisar, simonbraunstein |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Alec Meyers
2011-02-12 17:46:44 UTC
I dont want any of upower, udisk, policykit or consolekit in my system. Like the bug opener I kicked upower and udisk out of the kdelibs ebuild. KDE works so far without any trouble. Please make this optional. Yes you can technicaly use the kde without it but most of the features will be broken or behaving differently from what we intended. Given the amount of bugreports this could generate like everytime when we give users experimental useflag (this time even unsupported by us and upstream) it is not worth the effort. The same issue goes with you guys not willing to emerge kdebase-startkde or kdebase-runtime-meta even tho it causes quite few apps to misbehave in really weird ways. Be happy you dont have to emerge hal itself nowdays. (I would close it as wontfix but i leave it up to decision of our lead) Alright, but how can udisks/upower be useful if they are backends for solid, and I don't actually have solid installed? (It's not a dependency of kdebase-runtime-meta.) Am I missing something? I would like to mention that Duncan on the mailing list provides a good explanation of the concerns: http://archives.gentoo.org/gentoo-desktop/msg_5c33d9b04e158a154d7d5610c4eb6502.xml Except that in my case, I don't even use the KDE Desktop, so the features provided by udisks/upower/consolekit/policykit are not even in any way useful. (Unfortunately I am not subscribed, so I can't reply there.) *** Bug 367289 has been marked as a duplicate of this bug. *** KDE developers inform me that udisks/upower are not required for the KDE Desktop either. Gentoo is supposed to be about choice, not forcing us to use things we don't want. Did that change sometime? Also, the KDE profiles already force USE=policykit; why not just force any new USE flags that are perceived as somehow "required" by Gentoo (yet not upstream, in this case)? Finally, this blocks Bug 367287, but I can't seem to change it. (In reply to comment #6) > KDE developers inform me that udisks/upower are not required for the KDE > Desktop either. If you build a full desktop without those (and preferably consolekit/policykit), and you could report back how it works, that would be helpful :) I compiled kde without udisk/upower/policykit/consolekit (custom ebuild;)). Works like a charm. It seems the Gentoo KDE team is content to force their "intentions" on everyone, despite a glib-free KDE being supported upstream, but at least there is a workaround: mkdir /etc/portage/profile/ -p # This allows you to turn off the policykit and consolekit USE flags: echo -e '-policykit\n-consolekit' >> /etc/portage/profile/use.force # This allows you to build kdelibs without udisks/upower: echo -e 'sys-power/upower-9999\nsys-fs/udisks-9999' >>/etc/portage/profile/package.provided KDE 4.6.2 is running flawlessly for me this way. No idea what the "Run as" nonsense that's supposed to be "broken"; I see no such option anywhere (possibly as a result of building without support for it). Basically perfect as far as I'm concerned. No, the Gentoo KDE Team in one of our meetings decided to actually make udisks/upower optional. I am responsible for this bug, but I didn't have time yet to work on it. If you (or any of you) wants to send me some patches, feel free to do so. My statement was based on the comments by scarabeus in this bug, and on IRC as recently as yesterday. Good to hear the team has decided to support this. Thanks. *** Bug 367025 has been marked as a duplicate of this bug. *** (In reply to comment #12) > No, the Gentoo KDE Team in one of our meetings decided to actually make > udisks/upower optional. I am responsible for this bug, but I didn't have time > yet to work on it. If you (or any of you) wants to send me some patches, feel > free to do so. What is it exactly that needs to be patched? Based on the comments here, it seems like all that's needed is to hide the two dependencies behind a USE flag, and add them to packages that must have them to function (like k3b, I think). Hi everyone, please get kdelibs-4.6.4-r2 from the kde overlay and test; it now has a "umagic" useflag (defaulting to on) for this purpose. I'll keep this bug open until the feature moves into the main tree (with 4.6.5 most likely). Please report any applications that REQUIRE udisks or upower HERE in this bug, and I'll add a dependency on kdelibs[umagic]. Cheers! (and yes I know the name of the useflag is silly, any better ideas?) (In reply to comment #16) Update... the umagic useflag is gone again (it was a silly name after all). Now, the udev useflag controls all the udev / upower / udisks dependencies. So, if you want to get rid of them, disable the udev useflag for kdelibs-4.6.4-r2 and later. Does that mean you lose udev-specific functionality too? If so, it's a bit absurd. udev doesn't have the same problems udisks/upower do. (In reply to comment #17) > Update... the umagic useflag is gone again (it was a silly name after all). Why not just have "udisks" and "upower" flags? ;) udisks? ( sys-fs/udisks ) upower? ( sys-power/upower ) (Assuming KDE uses udev for things other than disks/power management) > [ebuild U ] kde-base/kdelibs-4.6.5 [4.6.4-r1] USE="-udisks% -upower%"
Thank you! :)
@dilfridge: are deps done? should we close this? I think we can close it. Probably packages that need kdelibs[xxx] here already have a dependency on xxx anyway. You should probably add the udisks dependency for K3b - I compiled it and, as I suspected, it does not detect an Optical Drive. (Back in the HAL days, it required hald to be started) No, udisks is not needed for k3b: export SOLID_HAL_LEGACY=1 k3b Add to a global or local profile for convenience. Obviously this needs HAL though, but IMHO it's better than depending on something that pulls in policykit/consolekit. Unfortunately the word "legacy" suggests this option will eventually disappear, at which point I guess I'll have to switch to non-KDE apps, unless someone can figure out how to permanently disentangle policykit/consolekit from certain KDE apps (a fork perhaps). But for now, at least, it works. Sorry, I meant: export SOLID_HAL_LEGACY=1 k3b |
