GNOME Bugzilla – Bug 581515
Don't build DeviceKit-disks by default
Last modified: 2012-08-11 16:06:41 UTC
The current src/gdu/Makefile.am uses hardcoded paths for "/usr/share/dbus-1/interfaces/org.freedesktop.DeviceKit.Disks.xml". This makes it hard to use in, say, jhbuild. Please apply the attached patch to use $(datadir) instead.
Created attachment 134056 [details] [review] use datadir
Actually it is that way, because when using jhbuild you want to use the DeviceKit-disks provided by the OS. It's not feasible (nor advisable) to build DeviceKit-disks as part of jhbuild since it depends on certain versions of the kernel, udev and other system-level components. So that's why it's hardcoded that way.
Furthermore, I think jhbuild should just cope with the gnome-disk-utility build failing (and, if so, also remove a previously installed version). Then components higher in the stack (such as GVfs) can be built without gnome-disk-utility support. This works since we guarantee that things can be built without gnome-disk-utility support. Thoughts?
Re: your first comment (gdu *should* hardcode it), I disagree. You're saying that people shouldn't build dkd from git? Ever? (obviously you don't mean that, but it sounds like what you're saying -- and the practical effect of hardcoding the path) Why go out of your way to disallow it? Very often, the person building it will have met the requirements and just wants to build/test the GNOME stack. If that is your concern (you feel a sizable percentage of people building from git will not meet the requirements), please add a configure flag to set the dkd path (e.g. --with-dkd=/usr/share) that defaults to datadir. That would let someone building from jhbuild either use the git-version (by default, because it's good to respect datadir) or use the system version (if for some reason they don't meet the requirements). Re: your second comment (jhbuild should cope with failures better), it does. I could have told jhbuild to ignore the failure and skip anyone that depends on gdu. Or I could have set it up to not try to build it and have every package compile with some configure flag that turns off gdu support. But that's not something I really expected to have to do, and don't think you should force everyone to do.
(In reply to comment #4) > Re: your first comment (gdu *should* hardcode it), I disagree. You're saying > that people shouldn't build dkd from git? Ever? (obviously you don't mean > that, but it sounds like what you're saying -- and the practical effect of > hardcoding the path) Why go out of your way to disallow it? Yes, that is what I'm saying. DeviceKit-disks is a component that requires very close integration with the rest of the OS, specifically the kernel and udev versions (and also mdadm versions). There's a thread on desktop-devel-list where I raised these concerns already. So, yes, I _actively_ go out of my way to ensure people don't shoot themselves in the foot by pretending they can run it on a system that do not meet the requirements. This is especially important as bugs in DeviceKit-disks actually means people losing data on their disks. By the same token, jhbuild doesn't pull in other stuff like glibc or HAL because it would be a nightmare to get right (and, trust me, people tried doing this with HAL and it never worked). > Very often, the person building it will have met the requirements and just > wants to build/test the GNOME stack. People should either get DeviceKit-disks from their distro vendor or build it themselves and install it into /usr. If users don't want this, the rest of the GNOME stack will build just fine without gnome-disk-utility support. > If that is your concern (you feel a sizable percentage of people building from > git will not meet the requirements), please add a configure flag to set the dkd > path (e.g. --with-dkd=/usr/share) that defaults to datadir. That would let > someone building from jhbuild either use the git-version (by default, because > it's good to respect datadir) or use the system version (if for some reason > they don't meet the requirements). This is not really going to work; you can't really build DeviceKit-disks with a prefix like /opt/gnome2 - we'd end up installing required udev rules, D-Bus .service files and other stuff into the wrong place. It's just messy. It's not that I'm trying to be a asshole here, just saying that experience from the HAL days has shown that it's not feasible to include DeviceKit-disks in jhbuild. DeviceKit-disks is a system-level component and either you have the appropriate version from your OS vendor (or you install it yourself) and you can get gnome-disk-utility. Or you don't, and you don't (and the rest of the GNOME stack will build just fine). David
OK! Thank you for the explanation, David. I'm changing this bug's component to jhbuild. As of now, the gnome-2.28 moduleset builds dkd by default. Sounds like we don't want that.
commit d02c9a1e957ffd15fed03dd59f55bc787ec04b6e Author: Frederic Peters <fpeters@0d.be> Date: Wed May 6 16:16:04 2009 +0200 [2.28] remove libatasmart and DeviceKit-disks from external deps DeviceKit-disks is too low in the stack to be part of JHBuild and the user should really have it installed system-wide. (GNOME #581515)
*** Bug 582096 has been marked as a duplicate of this bug. ***
*** Bug 583836 has been marked as a duplicate of this bug. ***
*** Bug 608325 has been marked as a duplicate of this bug. ***
*** Bug 614240 has been marked as a duplicate of this bug. ***
*** Bug 678712 has been marked as a duplicate of this bug. ***
*** Bug 681652 has been marked as a duplicate of this bug. ***