After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 673135 - [patch] make hardcoded D-Bus and XDG paths configurable
[patch] make hardcoded D-Bus and XDG paths configurable
Status: RESOLVED WONTFIX
Product: glib
Classification: Platform
Component: build
2.32.x
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-03-30 04:36 UTC by camillo.lugaresi+gnome
Modified: 2012-03-31 08:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (4.81 KB, application/octet-stream)
2012-03-30 04:36 UTC, camillo.lugaresi+gnome
Details
macro (1.35 KB, application/octet-stream)
2012-03-30 04:36 UTC, camillo.lugaresi+gnome
Details

Description camillo.lugaresi+gnome 2012-03-30 04:36:08 UTC
Created attachment 210916 [details]
patch

gio/gdbusprivate.c hardcodes the path "/var/lib/dbus/machine-id". However, if dbus is installed in a non-standard location (which is common with some package managers on some platforms, e.g. OS X), then the machine-id file ends up in a different prefix. This patch makes it configurable using the localstatedir option of configure.

gio/xdgmime/xdgmime.c similarly hardcodes the paths "/usr/local/share/:/usr/share/". With the same rationale, a path with a different prefix can be added at the beginning of the path list, using the datadir option of configure.

To expand the paths correctly, I used the as-ac-expand.m4 macro that Dbus also uses. It should be places in m4macros.
Comment 1 camillo.lugaresi+gnome 2012-03-30 04:36:48 UTC
Created attachment 210917 [details]
macro
Comment 2 Dan Winship 2012-03-30 12:26:48 UTC
"/usr/local/share:/usr/share" is specified by the XDG directory spec (http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html), meaning non-glib-based software will make the same assumption. If you install packages elsewhere, you have to set XDG_DATA_DIRS in the default environment to override the default definition. (Just like you have to update PATH in the default environment for people to be able to run the binaries in the first place.)
Comment 3 camillo.lugaresi+gnome 2012-03-30 19:56:27 UTC
However, if you install shared-mime-info to the same prefix, it puts the files in the same directory that my patch makes glib search. It makes more sense to me that the two programs would be able to find each other if they're installed to the same prefix, or, in general, by the same package manager. pkg-config works towards that goal, too.
PATH is more of a matter of convenience to me: you can easily run programs outside of PATH.
Comment 4 Matthias Clasen 2012-03-30 21:31:35 UTC
As Dan says, we're implementing the basedir spec here, and if you want a different path, just set the environment variable. Looking for the machine id in any other place than /etc (or /var/lib/dbus) doesn't make sense.
Comment 5 camillo.lugaresi+gnome 2012-03-31 08:26:31 UTC
Keep in mind that not everyone who builds glib is packaging a Linux distribution. Say you're working on a platform that doesn't come with glib or dbus built-in (e.g. OS X). Say you don't have admin access to the machine (e.g. a shared computer in a lab). There is going to be no machine id in /etc or /var/lib/dbus, nor can you put it there. What can you do is install dbus to a custom prefix, and dbus will happily install and put the machine id file there. You can also install glib to that prefix, and it will also happily install, but as of now it will refuse to look at dbus's machine file. I think it would be much better if it were able to find it.