Re: launch helper exited with unknown return code 127

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

_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus