GNOME Bugzilla – Bug 647927
Problem in dbus migration guidelines
Last modified: 2013-10-24 16:05:51 UTC
The applets dbus migration guidelines at http://live.gnome.org/GnomeGoals/AppletsDbusMigration have a problem, I think. It says the Makefile.am should contain this line: appletdir = $(LIBPANEL_APPLET_DIR) This causes the *.panel-applet files to be installed into the proper place as reported by pkg-config (LIBPANEL_APPLET_DIR=`$PKG_CONFIG --variable=libpanel_applet_dir libpanelapplet-4.0`). However, the problem is that this ignores the --prefix option given to configure. Performing a 'make install' installs all files to --prefix except the *.panel-applet files. But this is required to test for proper installation and for packaging. I think that line should read: appletdir = $(datadir)/gnome-panel/4.0/applets as the dbus service dir line already reads servicedir = $(datadir)/dbus-1/services This is similar to bug 646594 and its attachment 185015 [details] [review]: https://bugzilla.gnome.org/review?bug=646594&attachment=185015 I am requesting clarification. Cheers, Enrico
Anyone commenting on this?
This works for me and allows me to create packages: http://git.gnome.org/browse/gnome-applets/commit/?id=c29ca83d411d116dc005a9405a63039f486a7bb1
any news for this?
The http://live.gnome.org/GnomeGoals/AppletsDbusMigration page still quotes the directory path in question. Why was this bug report flagged as obsolete then?
As I explained in https://mail.gnome.org/archives/gnome-flashback-list/2013-October/msg00051.html (excerpt attached below), it is the intended behavior to always install into gnome-panel's prefix, because otherwise gnome-panel wouldn't find the new applet. That mail lists some workarounds for corner cases. Closing as NOTABUG. --- I think the behavior as shipped is absolutely correct, and the bug reporter is in error. Let me elaborate: A casual user, that compiles and installs applets to /opt/whereever, but uses a system-wide gnome-panel (or one int /opt/somewhereelse ), still _needs_ to install into the directory that gnome-panel actually will look at. Yes, that might (annoyingly) prompt the user for root rights, correct. But if gnome-panel cannot find the new applet, because the build system made up a path on the spot, that'll be a quite worse user experience. [...] Distributions would typically compile with --prefix=/usr and use something like fakeroot to avoid root permission issues. As a possible work-around for weird build [setups] or distribution problems, note that you can create special local-only .pc files that will override the normal ones. They need to be named like libpanel-applet-4.0-uninstalled.pc (refer to the pkg-config manual for details). > The solution that the bug suggests is to replace LIBPANEL_APPLET_DIR > macro by > > appletdir = $(datadir)/gnome-panel/4.0/applets > > but then we actually hard code 4.0 in a lot of places. Currently we > actually do neither of both in gnome-panel, instead we have: > > appletdir = $(appletsdir) > > and appletsdir is defined in configure.ac as: > > AC_SUBST([appletsdir],"\$(datadir)/gnome-panel/\$(LIBPANEL_APPLET_API_VERSION)/applets") > > > LIBPANEL_APPLET_DIR on the otherhand should expand to: > > AC_SUBST([appletsdir_pkgconfig],"\${datadir}/gnome-panel/\${libpanel_applet_api_version}/applets") > > > which is actually almost the same, but I cant find the place where its > actually defined? None of these solutions, when compiling out-of-tree applets, will actually cover the above use-case, and so are no-gos in my book. > Does anyone on this list have enough automake knowledge to explain > whats going on? > > See also commit: c45e8043dc107a7dff1c7eb46074f6d85724ad13 (by Vincent > Untz in 2011-01-31) The autoconf magic here is just the initial definition for the path for _the currently-built installation of gnome-panel_ (and the libpanel-applet-4.0.pc that should later allow for compatibility with it). Once that is built, the external applets _should_ try to install to the directory derived at panel configure time. Cheers Philipp