View previous topic :: View next topic |
Author |
Message |
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Mon Jun 06, 2016 10:39 pm Post subject: [solved] install KDE5 apps without udisks dependency hell? |
|
|
I'm trying to upgrade from calligra-2.9.11 to krita-3. One of the things I consistently see KDE 5 hyped for is that it's "more modular" and doesn't require anywhere near the mountain of unused crap I currently need to have installed for Calligra. Getting rid of yet-another-webkit-I-don't-need would certainly be nice.
But when I do emerge -ptv krita, I see this:
Code: | [ebuild N ] sys-fs/udisks-2.1.7:2::gentoo USE="gptfdisk -acl -cryptsetup -debug -introspection (-selinux)
-systemd" 899 KiB
[ebuild N ] dev-libs/libatasmart-0.19-r1::gentoo USE="-static-libs" 252 KiB
[ebuild N ] virtual/eject-0::gentoo 0 KiB
[ebuild N ] sys-apps/gptfdisk-1.0.1::gentoo USE="ncurses -static" 191 KiB
[ebuild N ~] sys-auth/polkit-0.113-r1::gentoo USE="nls -examples -gtk -introspection -jit -kde -pam (-seli
nux) -systemd {-test}" 1,415 KiB
[ebuild N ~] dev-lang/spidermonkey-1.8.5-r5:0/mozjs185::gentoo USE="-debug -minimal -static-libs {-test}"
6,021 KiB
[ebuild NS ] sys-devel/autoconf-2.13:2.1::gentoo [2.69-r2:2.69::gentoo] 434 KiB
[ebuild N ] sys-auth/consolekit-1.1.0::gentoo USE="policykit -acl -cgroups -debug -doc -pam -pm-utils (-
selinux) {-test}" 628 KiB
[ebuild N ~] sys-block/parted-3.2-r1::gentoo USE="debug nls readline -device-mapper (-selinux) -static-lib
s" 1,617 KiB |
I'm not interested in installing crapkit to give a desktop access to my raw disk partitions, let alone a drawing program. This problem is coming from kde-frameworks/solid and I don't see any USE flags or other way to disable this junk. Should I just give up trying?
Last edited by Ant P. on Tue Jun 07, 2016 7:06 pm; edited 1 time in total |
|
Back to top |
|
|
geki Advocate
Joined: 13 May 2004 Posts: 2387 Location: Germania
|
|
Back to top |
|
|
Section_8 l33t
Joined: 22 May 2004 Posts: 627
|
Posted: Tue Jun 07, 2016 1:35 pm Post subject: |
|
|
Just glancing thru the output there, setting use="-policykit" on consolekit might cut it back some. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Tue Jun 07, 2016 2:17 pm Post subject: |
|
|
shows that this indeed has a hard dependency on udisks:2. If you cannot avoid the dependency on solid, you are lost. The udisks (and thus polkit) dependency is one of the reasons why I dumped kde5 already quite a while ago. (The other reason is the semantic desktop nonsense which is even more worrying concerning privacy.) |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Tue Jun 07, 2016 5:25 pm Post subject: |
|
|
I decided to say to hell with it and throw a blank udisks ebuild in my local overlay. Will follow up (probably a few hours from now) if it works...
update: works fine! |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Wed Jun 08, 2016 9:13 am Post subject: |
|
|
Ant P. wrote: | update: works fine! |
Good to hear! However, I suspect that a lot of KDE applications will cease to work (e.g. k3b and other CD/DVD rippers/players).
Anyway, perhaps one could suggest the gentoo KDE team to support an USE=udisks flag and make a USE-dependency for the corresponding applications? |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8933
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Wed Jun 08, 2016 9:47 am Post subject: |
|
|
The reply in this bug appears strange to me:
If the backend for udisks can be built without having udisks (which apparently is the case according to Ant P.'s posting then having sys-fs/udisks:2 in DEPEND is completely wrong.
Even having it in RDEPEND is wrong, as it is not needed for any packages using solid: The package will work and run, only the udisks stuff will not do the thing the package uses it for, i.e. udisks should instead be a dependency of the package or of a corresponding feature of the package (hence perhaps also be controllable by a USE-flag if it does not control the only functionality of the package).
If my above understanding of the situation is correct, then the reply means that the developer is too lazy to care about correct dependencies and prefers unnecessary dependencies over spending some time of work (and fixing possible bug reports of missing dependencies). This is perhaps valid, but then he should be honest enough to admit that and not pretend a technical reason as the cause. (The technical reason would be that solid does not build without udisks without patching which is how I would have understood the reply if I wouldn't know Ant P.'s contrary experience.) |
|
Back to top |
|
|
kensington Developer
Joined: 02 Jan 2013 Posts: 177 Location: Australia
|
Posted: Wed Jun 08, 2016 3:13 pm Post subject: |
|
|
mv wrote: |
The reply in this bug appears strange to me:
If the backend for udisks can be built without having udisks (which apparently is the case according to Ant P.'s posting then having sys-fs/udisks:2 in DEPEND is completely wrong.
Even having it in RDEPEND is wrong, as it is not needed for any packages using solid: The package will work and run, only the udisks stuff will not do the thing the package uses it for, i.e. udisks should instead be a dependency of the package or of a corresponding feature of the package (hence perhaps also be controllable by a USE-flag if it does not control the only functionality of the package).
If my above understanding of the situation is correct, then the reply means that the developer is too lazy to care about correct dependencies and prefers unnecessary dependencies over spending some time of work (and fixing possible bug reports of missing dependencies). This is perhaps valid, but then he should be honest enough to admit that and not pretend a technical reason as the cause. (The technical reason would be that solid does not build without udisks without patching which is how I would have understood the reply if I wouldn't know Ant P.'s contrary experience.) |
The whole point of solid is abstraction - the application built on top of it doesn't need to care what platform or device management is used.
On Linux systems, upstream unconditionally builds the udev and udisks backends. They used to be optional, but upstream got sick of bogus bug reports about things not working because most of solid's useful features require udisks.
If solid unconditionally provides a backend that calls udisks at runtime via dbus, why do you think udisks is not a valid dependency? |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Wed Jun 08, 2016 5:36 pm Post subject: |
|
|
kensington wrote: | If solid unconditionally provides a backend that calls udisks at runtime via dbus, why do you think udisks is not a valid dependency? |
I take it from the einfo message in the solid ebuild there's already other magic runtime dependencies. Why the inconsistency? |
|
Back to top |
|
|
kensington Developer
Joined: 02 Jan 2013 Posts: 177 Location: Australia
|
Posted: Wed Jun 08, 2016 5:42 pm Post subject: |
|
|
Ant P. wrote: | kensington wrote: | If solid unconditionally provides a backend that calls udisks at runtime via dbus, why do you think udisks is not a valid dependency? |
I take it from the einfo message in the solid ebuild there's already other magic runtime dependencies. Why the inconsistency? |
Upstream explicitly states that app-misc/media-player-info is runtime-only optional dependency. They make no such claim about udev/udisks, and in fact deliberately changed udev/udisks to be mandatory at build time because of problems reported when it was missing. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Fri Jun 10, 2016 8:44 am Post subject: |
|
|
kensington wrote: | If solid unconditionally provides a backend that calls udisks at runtime via dbus |
Because it is only one backend, and solid (though not the backend) will function without it.
For instance, several zsh completion functions break if some tools are not available. The user or some other library/tool might trigger that function and thus cause breakage if not all tools are installed for which the backends (completion functions) are available. Of course, this is not a reason to make these tools a hard runtime dependency of zsh - it is considered the reliability of the user to not trigger that backend (or pick up the pieces if he does).
Quote: | They make no such claim about udev/udisks, and in fact deliberately changed udev/udisks to be mandatory at build time |
This does not seem to be the case for udisks, according to Ant P.: He seemed to be able to build without udisks without any patches.
As mentioned, I understand that it is upstream's intention to shove udisks (+polkit BS) down our throats for their convenience (to not receive "invalid" bug reports etc.) and that gentoo might want to follow upstream's policy for whatever reason (good future cooperation, less bug reports/complaints in gentoo etc.). But then one should be honest and say that this is a political decision and not pretend a technical reason. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Fri Jun 10, 2016 7:44 pm Post subject: |
|
|
It doesn't seem worth the effort to argue about, IMO. The KDE herd used to be fine with this (grep ewarn kde4-base.eclass) but I guess upstream wanted to be nasty about it. |
|
Back to top |
|
|
|