'no_polkit' variant for Gconf (was Re: Inkscape as non-root? (-> gnome-vs -> gconf -> policykit -> fail))
devans at macports.org
Fri Jul 31 08:05:07 PDT 2009
> To clarify my initial intentions: I used MacPorts to install all needed
> libraries and helper applications for Inkscape, but then proceeded to
> build the application itself using the instructions on the Inkscape Wiki
> page <http://wiki.inkscape.org/wiki/index.php/CompilingMacOsX> as
> guidelines (i.e. I didn't not use the MacPorts Portfile for Inkscape).
> My goal was to create the 'Inkscape.app' bundle with the most recent
> updates from SVN.
I'm aware of this approach and am working to implement a similar
approach within the Inkscape
port for the release of 0.47 that will hopefully build either as an X11
app or a native quartz
build (+quartz variant on MacPorts) so be aware that some parallel work
is going on. The
latest 0.47 prerelease is available as port inkscape-devel (but as yet
without the .app bundling).
>> Dbus is also used directly by many applications. For instance it is
>> used by GIMP to make sure that only one instance
>> of GIMP is active at a time.
> I currently have GIMP 2.6.6 from gimponosx.sf.net installed, and had a
> look at how it implements its dbus-dependencies by including its own
> dbus-daemon/launcher into the application bundle.
Port gimp-app provides the .app bundling on MacPorts. The meta port
gimp will install GIMP
with all dependencies and additional plugins as well. Use +animation to
get gimp-gap 2.6 as
> Dbus will need to be part of the Inkscape port (and any Inkscape
> application bundle) as soon as the new GSoC 2009 project implementing a
> scripting API via dbus makes it into the trunk. Until then Inkscape
> seems to run fine without it, even with a broken GConf install (except
> Open ClipArt Library access).
> In my limited experience the increasingly(?) complex nature of GNOME
> seems to undermine the ability of MacPorts to run as non-admin at user
> level. How many ports of applications like Inkscape, Dia or Gimp can
> still be installed without some of the deeply nested dependencies
> requiring sudo-access in the destroot/install/activation phase?
Note that the ability to use MacPorts without the need to use sudo is a
relatively new feature.
The historical usage has always to use sudo. This is consistent with
the way applications
are installed on MacOS X where you are prompted to supply a password to
the install. So there are gotchas in the process when you try to avoid
this entirely. A good
class of ports that probably need sudo are those that provide a server
such as apache, mysql,
bind9 etc. All of these use launchd to lauch the server at startup.
> I will try to figure out how launch and controll a dbus-session at user
> level next, before I have to give up and acknowledge that the use of
> sudo/admin rights is definitely not avoidable.
You might want to search our trac for tickets reported against dbus for
some historical perspective
on how the current configuration evolved and the problems that people
have run into before.
Note also that the primary assumption of MacPorts is that you will be
using MacPorts for all
phases of building your software and so mixing MacPorts builds with
is not recommended.
See http://trac.macports.org/wiki/FAQ#ownlibs for a partial
explaination of the rationale.
More information about the macports-users