Currently sys-fs/udisks hard depends on sys-auth/polkit; even worse with daemon use. This makes it hard to have installed without polkit whitch comes itself even with circular dependencies. One of the big troubles with polkit is that it intersepts sleep events what even produce a security risk as for example, there is no time to lock display before the system went to sleep. That to say, polkit is not needed for udisks in any cases; especially when usidsks is only pulled in by sys-apps/fwupd.
As far as I can see, udisks does need polkit: https://github.com/storaged-project/udisks/pull/857 and https://github.com/storaged-project/udisks/pull/857#issuecomment-1023357601. > This makes it hard to have installed without polkit whitch comes itself even with circular dependencies. ?
About the dependency. They wrote that it is an integral dependency for the daemon. But I do not intent to run any udisks daemon. I just have it installed as another useless dependency from fwupd. There is even an daemon use but polkit is used outside of that dependency. About the circular dependencies, it is not subject of this bug but: polkit -> gnome-extra/polkit-gnome -> polkit... (with gtk use) and there are others I seen in the past.
(In reply to Klaus Ethgen from comment #2) > About the dependency. They wrote that it is an integral dependency for the > daemon. But I do not intent to run any udisks daemon. I just have it > installed as another useless dependency from fwupd. There is even an daemon > use but polkit is used outside of that dependency. The build system unconditionally requires polkit. Has something changed since that PR was rejected?
Note that I at least am not necessarily against patching udisks if it can be done in a non-invasive way, but it's not clear if you're aware that it seems to unconditionally require it and that the ebuild is correct as-is (or if that's wrong, please explain how). But I'd also really like to see another attempt to upstream such a change first.
