GNOME Bugzilla – Bug 693590
NetworkManager might use different libexecdir than gnome-shell
Last modified: 2013-04-19 22:23:29 UTC
In openSUSE, for example (debian seems to do similar things), gnome-shell is condifured with configure --libexecdir=/usr/lib/gnome-shell and NetworkManager accordingly with configure --libexecdir=/usr/lib/NetworkManager => gnome-shell fails to understand this and looks for the NM vpn agents in /usr/lib/gnome-shell A possible solution (patch to be attached) is to introduce a --with-nmlibexecdir configure variable, which distributions can make use of instead of patching the code (as done in Debian at the moment)
Created attachment 235702 [details] [review] Introduce --with-nmlibexecdir
For reference, debian has this patch: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-shell/debian/patches/27-nm-libexec-path.patch?view=markup (which could be replaced by above upstream fix and ./configure --with-nmlibexecdir=/usr/lib/NetworkManager )
Thats just not a scalable solution - configuring the libexecdirs of dependencies 1-by-1.. Setting private libexecdirs is just not compatible with its role as cross module api
It's more scalable than having all dists patching the code base in the end imho. and the fact that dists DO use different libexecdirs is also a given.
Review of attachment 235702 [details] [review]: I agree with Matthias. However if NetworkManager added something like plugin_execdir to its pkg-config file, I'd be fine with picking that up (there is a libgnome_server variable, but I haven't seen any plugins using it, so I guess it's something different).
(In reply to comment #5) > Review of attachment 235702 [details] [review]: > However if NetworkManager added something like > plugin_execdir to its pkg-config file, I'd be fine with picking that up That's typically the best solution for things like this. As far as libexecdir - I think only Fedora actually sets it to /usr/libexec, everyone else does the /usr/lib/pkgname thing.
Ahem... people... before we start patching the shell, there is a GLib.path_is_absolute() check right there: can't you just put those absolute paths in the VPN agent keyfile, like Arch does? (Yes, they were the first to report this, back in 3.4)
(In reply to comment #5) > Review of attachment 235702 [details] [review]: > > I agree with Matthias. However if NetworkManager added something like > plugin_execdir to its pkg-config file, I'd be fine with picking that up Yeah, we can do that. We already added "plugindir" (which is $libdir rather than $libexedir) for gnome-control-center.
(In reply to comment #8) > (In reply to comment #5) > > Review of attachment 235702 [details] [review] [details]: > > > > I agree with Matthias. However if NetworkManager added something like > > plugin_execdir to its pkg-config file, I'd be fine with picking that up > > Yeah, we can do that. We already added "plugindir" (which is $libdir rather > than $libexedir) for gnome-control-center. +1 from me
(In reply to comment #8) > (In reply to comment #5) > > Review of attachment 235702 [details] [review] [details]: > > > > I agree with Matthias. However if NetworkManager added something like > > plugin_execdir to its pkg-config file, I'd be fine with picking that up > > Yeah, we can do that. We already added "plugindir" (which is $libdir rather > than $libexedir) for gnome-control-center. I changed my mind on this; this just changes the arbitrary constraint from "gnome-shell must use the same prefix as the NM VPN plugins" to "the NM VPN plugins must use the same prefix as NM". While that's somewhat more plausible, there's still no real reason for it. In master (and eventually 0.9.8.2, which should be in GNOME 3.8), all of the VPN plugin .name files include full paths.
I'm happy with Dan's solution and don't think more needs to be done; the responsibility has been waved to another part...