Yes, agree, the udisks dependency is a too high version. 

But udisks is very low in the stack. It is difficult to compile, and when you do compile it isn't system integrated.

I'm not sure how to solve this one.

david is explicitly against building udisks in jhbuild

cf bug 581515 comment 5.

we really need to reconsider this one.

with reference to our discussions at the Boston Summit, there seemed to be some agreement that the tangible end-user deliverables of the GNOME project would be:

  1) ostree
  2) jhbuild on the latest version of fedora
  3) jhbuild on the latest version of ubuntu (and possibly the LTS release)

we can't do 3 unless we have

  1) udisks in jhbuild
  2) gnome-disk-utility depending on udisks only optionally
  3) gnome-disk-utility out of the modulesets

i don't really like 2 or 3...

i think having udisks in jhbuild, if only for the library side of it, is something we should seriously consider...

The current situation is a bit insane.

gnome-disk-utility in git master is currently depending on an *unreleased* version of udisks2 (2.0.90).

Seriously.... we either need udisks in jhbuild or gnome-disk-utility out...  either that, or these two components need to re-evaluate their relationship with each other.

for the record, udisks would not be the only component that we build that installs a system service.

org.freedesktop.Accounts.service
org.freedesktop.ColorManager.service
org.freedesktop.Gypsy.service
org.freedesktop.nm_dispatcher.service
org.freedesktop.PackageKit.service
org.freedesktop.PolicyKit1.service
org.freedesktop.realmd.service
org.freedesktop.UPower.service
org.gnome.GConf.Defaults.service

Created attachment 230050 [details] [review]
3.8: add udisks to the modulesets

I talked to David about this on IRC and he says that the above patch is fine with him.

ACK

Attachment 230050 [details] pushed as aff7be7 - 3.8: add udisks to the modulesets