kdelibs-4.9.98 added an rdep on udisks, which in turn brings in a huge pile of its own dependencies, many of which complicate the system, making updates and sysadmin security supervision and control more difficult than need be. The general kde GUI works without it, and I'd prefer to handle mounting, etc, myself anyway, especially when NOT doing so pulls in such complex deps. Here's what udisks would pull in on my system: Calculating dependencies ....... done! [ebuild N ] sys-apps/acl-2.2.51 USE="(-nfs) -nls -static-libs" 377 kB [ebuild N ] virtual/acl-0-r1 USE="-static-libs" 0 kB [ebuild N ] dev-util/gdbus-codegen-2.34.3 PYTHON_TARGETS="python2_7 -python2_5 -python2_6 -python3_1 -python3_2 (-python3_3)" 0 kB [ebuild N ] dev-lang/spidermonkey-1.8.8:0/mozjs188::mozilla USE="jit -debug -minimal -static-libs {-test}" 4,095 kB [ebuild N ] dev-libs/libatasmart-0.19 USE="-static-libs" 0 kB [ebuild N ] sys-block/parted-3.1-r1 USE="readline -debug -device-mapper -nls (-selinux) -static-libs {-test}" 1,489 kB [ebuild N ] sys-auth/polkit-0.110 USE="pam -examples -gtk -introspection -kde -nls (-selinux) (-systemd)" 1,358 kB [ebuild N ] sys-auth/consolekit-0.4.5_p20120320-r1 USE="pam policykit -acl -debug -doc (-selinux) {-test}" 0 kB [ebuild R ] sys-auth/pambase-20120417-r2::kde USE="consolekit* sha512 -cracklib -debug -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc (-selinux) -systemd" 0 kB [ebuild N ] sys-fs/udisks-2.0.91:2 USE="-crypt -debug -gptfdisk -introspection (-selinux) (-systemd)" 795 kB Total: 10 packages (9 new, 1 reinstall), Size of downloads: 8,112 kB The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) #required by sys-auth/polkit-0.110, required by sys-fs/udisks-2.0.91, required by udisks (argument) >=sys-auth/consolekit-0.4.5_p20120320-r1 policykit #required by sys-auth/polkit-0.110[pam], required by sys-fs/udisks-2.0.91, required by udisks (argument) >=sys-auth/pambase-20120417-r2 consolekit acl? WTF I need it for? parted and libatasmart? Arguably reasonable deps for udisks' intended purpose, but they're still rather heavy deps for functionality I don't particularly want/need in the first place. Then there's the whole consolekit/polkit/spidermonkey thing that's actually the trigger for this bug. Consolekit and polkit are both rather complex from a sysadmin security administration perspective, and all they've brought me in the past is grief when something goes wrong and I have to figure out how to fix a problem I should have never had in the first place, as I don't need nor want the functionality those packages provide. I'll freely admit to not understanding the security config, and I know for sure that kde with them installed wants to grant kde/GUI users way more permissions than I'm comfortable with them having. Controlling such permissions is what sudo and its config (which I *DO* grok reasonably well) is for, and why I've managed USE flags and chosen packages so consolekit/polkit are not installed now, and why I strongly object to having them pulled in for udisks, which as I said, I shouldn't have to be dealing with in the first place, as its functionality I don't need nor want. So please put the udisks rdep under a USE flag. It can be +udisks if desired, but having that sort of not entirely necessary (r)dep managed by USE flags is exactly why a lot of folks (including me) run gentoo in the first place. FWIW, I'm currently running with udisks in package.provided. No problems yet, thru 4.9.98 (with 4.10.0 still building when I started this, it looks to be done now). But I really don't like to package.provided a package that's not actually installed... tho it beats manually overlaying an ebuild at every bump.
This change was introduced due to upstream changes: if ( WITH_SOLID_UDISKS2 ) message(STATUS "Building Solid UDisks2 backend." ) add_definitions(-DWITH_SOLID_UDISKS2) set(solid_LIB_SRCS ${solid_LIB_SRCS} backends/udisks2/udisksmanager.cpp backends/udisks2/udisksdevice.cpp backends/udisks2/udisksdevicebackend.cpp backends/udisks2/udisksblock.cpp backends/udisks2/udisksstoragevolume.cpp backends/udisks2/udisksdeviceinterface.cpp backends/udisks2/udisksopticaldisc.cpp backends/udisks2/udisksopticaldrive.cpp backends/udisks2/udisksstoragedrive.cpp backends/udisks2/udisksstorageaccess.cpp backends/udisks2/udisksgenericinterface.cpp backends/udisks2/dbus/manager.cpp ) else ( WITH_SOLID_UDISKS2 ) message(STATUS "Building Solid UDisks backend." ) set(solid_LIB_SRCS ${solid_LIB_SRCS} backends/udisks/udisksmanager.cpp backends/udisks/udisksdevice.cpp backends/udisks/udisksblock.cpp backends/udisks/udisksstoragevolume.cpp backends/udisks/udisksdeviceinterface.cpp backends/udisks/udisksopticaldisc.cpp backends/udisks/udisksopticaldrive.cpp backends/udisks/udisksstoragedrive.cpp backends/udisks/udisksstorageaccess.cpp backends/udisks/udisksgenericinterface.cpp ) endif ( WITH_SOLID_UDISKS2 ) We can try to patch it but please complain upstream too and let us know.
Just added a patched kdelibs to my overlay: https://github.com/ff2000/gentoo-overlay It completely removes the ability to build with udisks1.
Created attachment 338252 [details, diff] [PATCH 1/2] kdelibs-4.10.0: make udisks2 optional udisks:0 has way less intrusive dependencies than udisks:2 , and AFAICT kdelibs has no trouble using it. There's a use mask on udisks2 somewhere though (which suits me fine), but might not be desired. I have only tested this by building and running the kde-based applications I normally use. (I don't use kwin & c.) I observed no problems.
Created attachment 338258 [details, diff] [PATCH 2/2] kdelibs-4.10.0: Make udisks optional This combines Franz' patches with my previous ebuild suggestion, giving a similar hierarchy of use flags as previous kdelibs versions. Testing is like the above. Both udisks,-udisks2 and -udisks,-udisks2 seem to work fine for me. I'm not sure about the required_use part, but both Franz' and the previous ebuild had it.
+ 07 Feb 2013; Michael Palimaka <kensington@gentoo.org> + +files/kdelibs-4.10.0-udisks.patch, kdelibs-4.10.0.ebuild: + Add patch by Franz Fellner <alpine.art.de@googlemail.com> to make udisks + support optional, wrt bug #455792. Seems to be working here, but please test!
(In reply to comment #3) > udisks:0 has way less intrusive dependencies than udisks:2 I'd disagree. They both have heavy deps, but different heavy deps. (udisks-1 aka udisks:0 at least used to pull in device-mapper, part of lvm2, which I'd consider a heavy dep for folks not using it already. Naturally you'd not be as likely to consider that a "heavy" dep if you're already using it for something else.)
This bug is related to bugs 424157 and 456010, but I'll let someone else figure out whether/how to mark the bug-deps.
(In reply to comment #7) > This bug is related to bugs 424157 and 456010, but I'll let someone else > figure out whether/how to mark the bug-deps. 424157 is about updating the udisks:2-patch (to get udisks:0 out of portage). With 4.10.0 this is obsolete, as udisks:2-backend comes with the kdelibs-tarball. 456010 seems to be caused by the non-optional dep on udisks:2 but offer USE="udev". This imho is an upstream bug, as building udisks2-backend needs their udev-lib and should NOT be built if udev is not found. At least it should throw an error when running cmake.
This looks to be working fine now, closing. Thanks to everyone for patches and testing.
