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 720118 - improve jhbuild paths manipulation
improve jhbuild paths manipulation
Status: RESOLVED FIXED
Product: jhbuild
Classification: Infrastructure
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Jhbuild maintainers
Jhbuild QA
Depends on:
Blocks:
 
 
Reported: 2013-12-09 18:03 UTC by Allison Karlitskaya (desrt)
Modified: 2014-01-02 15:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
config: fix XDG basedir compliance (1.39 KB, patch)
2014-01-01 21:34 UTC, Allison Karlitskaya (desrt)
committed Details | Review

Description Allison Karlitskaya (desrt) 2013-12-09 18:03:58 UTC
jhbuild sets a bunch of things like XDG_DATA_DIRS, PKG_CONFIG_PATH, XDG_CONFIG_DIRS, GI_TYPELIB_PATH, etc. but there are some deficiencies in how it does so.

For example, the basedir spec says that the default value of XDG_DATA_DIRS is /usr/local/share:/usr/share but jhbuild defaults to only /usr/share.

Another example is GI_TYPELIB_PATH getting set to /usr/lib or /usr/lib64 depending on the value of 'use_lib64', which is a bit strange -- why should our preference of if we use lib64 or not have anything to do with where we search for things on the system?  We should query the default typelib path out of the system-installed gobject-introspection.
Comment 1 John Ralls 2013-12-09 20:04:30 UTC
The default XDG_DATA_DIRS should be ${prefix}/share:/usr/local/share:/usr/share

Any change to use the system-installed gobject-introspection should be prepared to handle the case where there isn't one, because jhbuild is being used to create it along with the rest of the Gtk stack.
Comment 2 Allison Karlitskaya (desrt) 2014-01-01 21:34:54 UTC
Created attachment 265113 [details] [review]
config: fix XDG basedir compliance

quoth the spec:

If $XDG_DATA_DIRS is either not set or empty, a value equal to
/usr/local/share/:/usr/share/ should be used.

If $XDG_CONFIG_DIRS is either not set or empty, a value equal to
/etc/xdg should be used.
Comment 3 Frederic Peters 2014-01-02 15:54:53 UTC
Comment on attachment 265113 [details] [review]
config: fix XDG basedir compliance

ok. (even as I'm not quite sure about the partial_build integration)
Comment 4 Allison Karlitskaya (desrt) 2014-01-02 15:57:42 UTC
Attachment 265113 [details] pushed as ee3d23c - config: fix XDG basedir compliance


Consulting partial_build here to decide if we should respect the XDG
spec or not was completely bogus.  I think it may have been a leftover
from a period where it was reasonably possible to jhbuild a system with
absolutely no help from any underlying component whatsoever.

In the modern era this is a testament to just how infrequently people
turn off partial_build -- any component from /usr that we included in
the build that tried to find its own data files would fail (and even
with partial_build off, there are a lot of those).