| Summary: | kde-4.6: impossible to switch off USE-flags -policykit -consolekit -device-mapper | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alex Efros <powerman-asdf> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gentoo |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Alex Efros
2011-05-27 20:20:11 UTC
You might try this to disable these flags globally: echo -e "-policykit\n-devicekit" >> /etc/portage/profile/use.force or you can do it on a package basis: echo "kde-base/kdelibs -policykit" >> /etc/portage/profile/package.use.force (mkdir the directory strucure in case it doesn't exist on your system) Dunno why KDE team is imposing this kind of... stuff on us but at least there's a way to get rid of it without manually editing the ebuilds... (In reply to comment #1) > You might try this to disable these flags globally: Sadly, but this doesn't works for me. Here is my setup: home ~ # grep -PR 'policykit|devicekit|consolekit' /etc/make.conf /etc/portage/ /etc/make.conf:USE="${USE} -policykit -consolekit -device-mapper" /etc/portage/package.use:sys-auth/consolekit policykit /etc/portage/profile/package.use.force:kde-base/kdelibs -policykit /etc/portage/profile/use.force:-policykit /etc/portage/profile/use.force:-devicekit /etc/portage/profile/use.force:-consolekit BTW, there is no "devicekit" flag, or at least `euse -i` doesn't know it. (In reply to comment #2) > BTW, there is no "devicekit" flag, or at least `euse -i` doesn't know it. Oh, right. I think I confused that one with -consolekit AFAICT this is due to udisks, which has a hard dependency on consolekit -> policykit. "semantic-desktop" (file indexing) seems to be a hard dependency for many KDE apps too, and I don't need/want it. (In reply to comment #4) > AFAICT this is due to udisks, which has a hard dependency on consolekit -> > policykit. > > "semantic-desktop" (file indexing) seems to be a hard dependency for many KDE > apps too, and I don't need/want it. WRT consolekit, kde-libs now has a useflag udisks. If you disable that you wont have any dependency on udisks and thereby consolekit. NOTE: udisks and consolekit is STRONGLY recommended if you run the KDE desktop environment. WRT semantic-desktop, well some apps just need it and it becomes more and more integrated into kde with newer releases. I can imagine us removing the useflag and force-enabling the features in the (far) future... Do I need these things (udisks, consolekit, polkit, semantic-desktop) to use applications like k3b, okular, amarok and kde games with fluxbox window manager? Same here. I only use Openbox, not KDE, and it's unlikely I ever will. I just happen to also run a handful of KDE apps, because there are no comparable alternatives (digiKam in particular). I think KDE developers/maintainers need to consider use-cases where people only want certain KDE apps, without forcing full KDE-desktop dependencies on them. I especially loath PolicyKit, for reasons that have been discussed at length elsewhere (e.g. Fedora). I much prefer to handle permissions and devices using more traditional, comprehensible and secure methods. I also have no use for indexing whatsoever. It's just a resource hog AFAIAC. On the extremely rare occasion I forget where I put a file, I'll just use the "find" command, thanks. Don't get me wrong, I really like a lot of KDE apps. I just wish KDE developers would stop assuming that everyone who runs KDE apps also runs a KDE desktop. Perhaps this could be added as a feature request upstream. But the thing is you CAN disable those dependencies via USE flags if you really need just 3rd party apps and you're ready to grab the pieces. It's just a matter of turning-off some defaults. And, do NOT use: USE="-someflag" emerge sth invocation because it WON'T record those changes - do it using package.use exclusively. And even if you think you know you don't need some dependency and it's hardcoded in some way - you can still use package.provided (bugs resulted from such setting will be invalid however). |