Getting a second MacPorts into action FAILS

[Ryan Schmidt]

On Oct 23, 2010, at 08:24, Marko Käning wrote:

>> --->  Activating dbus @1.2.24_1
>> Error: Target org.macports.activate returned: Image error: /Library/LaunchAgents/org.freedesktop.dbus-session.plist already exists and does not belong to a registered port.  Unable to activate port dbus. Use 'port -f activate dbus' to force the activation.
>> Log for dbus is at: /opt/macports-test/var/macports/logs/_opt_macports-test_var_macports_sources_rsync.macports.org_release_ports_devel_dbus/main.log
>> Error: Status 1 encountered during processing.
>> ---
> is all not necessary, since as one can see those services are normally not started:
> ---
> $ launchctl list | grep dbus
> $
> ---
> 
> But even if they get started one could avoid this trouble by including the MacPorts prefix in the plist's file name like this for instance:
> 
> /Library/Lauch(Agents|Daemons)/org.freedesktop.dbus-session.opt.local.plist
> /Library/Lauch(Agents|Daemons)/org.freedesktop.dbus-session.opt.macports-test.plist
> 
> Then there would be no confusion about as to which dbus.plist one should symlink to.
> 
> How about this, Michael? Anything against this approach?


I don't think we should go changing the names of the plists.

Rather, it feels to me that dbus is in error to be installing these plists into /Library/Launch* even when startupitem_type is set to none, which it is in my secondary MacPorts installations. dbus is the only port (I know of) that has this issue, but probably other ports that manually install launchd plists will have it as well. These ports should check the startupitem type and not install the plists if it is none.