GNOME Bugzilla – Bug 790367
wrong install_dir for glib-pacrunner.service on 64bit arches
Last modified: 2017-11-21 22:52:12 UTC
Building glib-networking 2.55.1 on x86_64 results in the following error: [ 6s] RPM build errors: [ 6s] File not found: /home/abuild/rpmbuild/BUILDROOT/glib-networking-2.55.1-0.x86_64/usr/lib/systemd/user/glib-pacrunner.service The patch in the attachment fixes this.
Created attachment 363671 [details] [review] The patch to fix this
Review of attachment 363671 [details] [review]: This looks correct. But looking a couple lines up, I see we've hardcoded the D-Bus service path as well. It should probably use the session_bus_services_dir pkg-config variable, just like you've done here for systemd. Want to fix that, too?
(In reply to Felix Zhang from comment #0) > Building glib-networking 2.55.1 on x86_64 results in the following error: > > [ 6s] RPM build errors: > [ 6s] File not found: > /home/abuild/rpmbuild/BUILDROOT/glib-networking-2.55.1-0.x86_64/usr/lib/ > systemd/user/glib-pacrunner.service > > The patch in the attachment fixes this. Thank you for reporting this Felix. The issue also extends to dbus, because the information regarding the D-Bus services path is in the dbus `.pc` file. Take a look here[0]. [0] https://git.gnome.org/browse/gvfs/tree/meson.build#n271
Created attachment 363760 [details] [review] build: Retrieve D-Bus and systemd paths Here goes the patch I was thinking on. It retrieves D-Bus and systemd related paths from the main meson.build file. This is done to centralize the checks necessary for every component. It also doesn't hold `dbus-1` and `systemd` dependencies in any object, as we only want to inspect paths variables, and those dependencies aren't used for building any object.
Review of attachment 363760 [details] [review]: Super!
Comment on attachment 363760 [details] [review] build: Retrieve D-Bus and systemd paths Pushed as 101561d - build: Retrieve D-Bus and systemd paths
Fixed, then, right?
(In reply to Philip Withnall from comment #7) > Fixed, then, right? It is on my system. However, I would appreciate very much if someone other than me would try it. That's why I haven't close this.
(In reply to Iñigo Martínez from comment #8) > (In reply to Philip Withnall from comment #7) > > Fixed, then, right? > > It is on my system. However, I would appreciate very much if someone other > than me would try it. That's why I haven't close this. Given that your patch is functionally identical to Felix’s, I think this is probably fixed. If anybody has a problem with the fix, they can always reopen the bug.
There has been some opposition to using paths from pkg-config. I think the original problem is that the systemd path here used libdir, but in fact it should be a hardcoded 'lib' because systemd does not use lib64.
(In reply to Michael Catanzaro from comment #10) > There has been some opposition to using paths from pkg-config. Why? From whom?
Emmanuele does not like packages installing outside of the install prefix. I don't either (though I thought it was convention to follow pkg-config when it breaks the rules).
This has historically been fixed in autotools build systems with a --with-systemduserunitdir argument to configure, or similar. The default is to get it from pkg-config if nothing is specified on the command line.
Emmanuelle has proposed another approach, which might be feasible. meson allows checking variables from dependencies (actually their correspondant `.pc` files). This is used to get those paths, for example the `giomoduledir` directory in `gio-2.0.pc` file. The `gio-2.0.pc` file is as follows in my system: prefix=/usr exec_prefix=${prefix} libdir=${prefix}/lib/x86_64-linux-gnu includedir=${prefix}/include giomoduledir=${libdir}/gio/modules glib_compile_schemas=${prefix}/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas glib_compile_resources=${prefix}/lib/x86_64-linux-gnu/glib-2.0/glib-compile-resources gdbus_codegen=gdbus-codegen Name: GIO Description: glib I/O library Version: 2.54.2 Requires: glib-2.0 gobject-2.0 Requires.private: gmodule-no-export-2.0 Libs: -L${libdir} -lgio-2.0 Libs.private: -lz -lresolv -lselinux -lmount Cflags: This means that replacing `libdir` in `.pc` file by the `libdir` option value used when building will allow it installing under prefix. Or even replacing the `prefix` could be replaced, which will also apply to `giomoduledir` through the `libdir` value which also is relative to prefix. pkg-config allows this by using the `--define-variable` option. I have modified meson (followed by a pull request[0]) to support this. I've also forked glib-networking by applying this approach[1]. [0] https://github.com/mesonbuild/meson/pull/2663 [1] https://gitlab.gnome.org/inigomartinez/glib-networking/commit/dcb65adde9c6fc88d0e586cf24ebe90e147822d9
I think Iñigo's suggestion would be OK with one change: only the prefix variable should be redefined, not any other variable.
Although the implementation would be useful under some conditions, it might not be the best option for this case. Let's take a look to the systemd's `.pc` file on my system (you can find the template here[0]), where `systemduserunitdir` is defined, which is used by `glib-networking`: prefix=/usr systemdutildir=/lib/systemd systemdsystemunitdir=/lib/systemd/system systemdsystempresetdir=/lib/systemd/system-preset systemduserunitdir=/usr/lib/systemd/user systemduserpresetdir=/usr/lib/systemd/user-preset systemdsystemconfdir=/etc/systemd/system systemduserconfdir=/etc/systemd/user `systemduserunitdir` is located under `prefix`, but the `.pc` file doesn't make the first relative to the latter, so replacing the `prefix` variable would not work in this case. The file could be modified by making those paths relatives to each other. However I hardly see this happening with all existing dependencies. [0] https://github.com/systemd/systemd/blob/master/src/core/systemd.pc.in
Created attachment 364143 [details] [review] build: Add options for system paths Until there is an agreement, here goes a patch that add options for those system paths (D-Bus, GIO and systemd paths). The user will be able to modify those paths and set them under prefix if desired.
This broke the SDK builder, since systemd is now required, but is not in the GNOME runtime. Until we have some other consensus, I'm going to go back to what we were doing before, just using 'lib' instead of libdir for systemd.
The following fixes have been pushed: 3dacd73 Fix glib-pacrunner.service install dir dffcc7e Revert "build: Retrieve D-Bus and systemd paths"
Created attachment 364154 [details] [review] Fix glib-pacrunner.service install dir This should be 'lib', not libdir, because systemd looks for unit files under /usr/lib/systemd, not /usr/lib64 and not under multiarch locations.
Created attachment 364155 [details] [review] Revert "build: Retrieve D-Bus and systemd paths" This reverts commit 101561dc4b28a4ab544c3a498003bc72eddaa63b.