A port is clashing with another program installed in /opt that is not a port

[Ryan Schmidt]

On Apr 2, 2012, at 08:33, Arno Hautala wrote:

> On 2012-04-02, Jerry wrote:
>> 
>> 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.
>> Error: Failed to install dbus
>> ----------------------
>> 
>> I looked at /Library/LaunchAgents/org.freedesktop.dbus-session.plist and
>> found that it is an alias that points to
>> 
>> /opt/openmodelica/Library/LaunchAgents/org.freedesktop.dbus-session.plist
>> 
>> It turns that I had some time back installed Open Modelica using a .mpkg
>> from a .dmg downloaded from http://openmodelica.org/, so that my /opt at the
>> upper levels looks like this:
>> 
>>    /opt/local
>>    /opt/openmodelica
>> 
>> If I take the suggestion by the MacPorts error message above to use 'port -f
>> activate dbus' will this disturb anything with my Open Modelica
>> installation?
> 
> So, the issue isn't that anything is installed into /opt/openmodelica,
> it's that Open Modelica and MacPorts dbus want to install a launchd
> plist to the same place.
> 
> I'm not familiar with Open Modelica, but it sounds like it installed
> it's own copy of dbus. It's possible that you could force the install
> without issue, but Open Modelica may be reliant on a specific version
> of dbus and run into issues when using the version supplied by
> MacPorts.
> 
> The dbus port does supply a "+no_startupitem" variant which should
> skip installing the launchd plist. The launchd task isn't started by
> default anyway and I think I recall that ports that depend on dbus are
> usually intelligent enough to start it on their own if it's not
> running (corrections welcome). I certainly don't recall running into
> any issues with having not started the launchd task.

There have been tons of reports over the years on the mailing list and in the issue tracker of problems resulting from users not reading and following the instructions the dbus port prints out:

$ port notes dbus
dbus has the following notes:
  ############################################################################
  # Startup items have been generated that will aid in
  # starting dbus with launchd. They are disabled
  # by default. Execute the following command to start them,
  # and to cause them to launch at startup:
  #
  # sudo launchctl load -w /Library/LaunchDaemons/org.freedesktop.dbus-system.plist
  # launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist
  ############################################################################

I am not familiar with dbus and don't use software that uses dbus, so I don't know if it will auto-start these daemons, but I have no reason to believe it will; if the above steps were not necessary to perform manually, I doubt the maintainer of the port would have gone to the trouble of adding the note.


> So, your best bet is to clean dbus and reinstall it with the
> "+no_startupitem" variant.
> 
> port clean dbus
> port install dbus +no_startupitem
> port install py-spyder
> 
> 
> It may also be worth while to report this issue to Open Modelica. I
> doubt that their launchd plist is required for operation.

If Open Modelica does not require dbus to be started, then it is the Open Modelica packagers who should be changing their distribution to use the +no_startupitem variant.


> Better Solution:
> 
> I notice that Open Modelica suggest using MacPorts to install their
> software. It may be best to remove the /opt/openmodelica directory,
> the launchd plist that linked to that directory, and any other OM
> files that you can find, and reinstall using MacPorts.

I absolutely agree.


> That you have files in /opt/openmodelica, a dbus plist that is linked
> in a similar way to how MacPorts manages things, and that the
> developers suggest using MacPorts to manage your installation suggests
> that the binary release that they've provided was created by a
> MacPorts installation from a custom prefix.

Clearly.