launch helper exited with unknown return code 127
Florin Gherendi
florin_gf at yahoo.fr
Tue Jun 7 07:16:55 UTC 2016
On 06/06/2016 07:31 PM, Simon McVittie wrote:
> On 06/06/16 14:08, Florin Gherendi wrote:
>> Some files location is "hardwired" inside the dbus
>> sources and will not adapt to --prefix=/opt/usr unless I make symlink to
>> where they are expected to be
>
> As far as I know, these should all be locations that are searched *in
> addition to* --prefix-based locations: for example we search
>
> /usr/local/share/dbus-1/system-services
> /usr/share/dbus-1/system-services
> ${datadir}/dbus-1/system-services
> /lib/dbus-1/system-services
>
> For you, ${datadir} would be /opt/usr/share. In particular, this should
> mean that services in /opt/usr/share/dbus-1 are found successfully, and
> you can safely ignore the other three.
>
> If you find any cases where that isn't true, please open a bug with
> specific details.
>
Hi again,
I will watch it again when upgrading to 1.10.8, I don't have the time to
do it right now. As far as I remember, the problems were not with
/opt/usr/share, but with /var/lib and /etc (machine_id, sockets and so on).
But some of the stuff I remember is surely also from glib2, where dbus
dirs *really are* hardwired, which can break communication between dbus
services and clients when installing in non-standard locations. I don't
quite understand why they chose that solution, since you don't really
want to compile dbus support in glib when you don't have dbus installed;
pkgconfig should know about the dbus prefix. Maybe something like a
"dbus-config" executable/script that would tell other programs about the
dbus files location could also be an elegant solution; but ok, I am not
a dbus developer
Cheers!
Florin
More information about the dbus
mailing list