selfupdate fails trying to synch with openmodelica (!)

[Jerry]

On Jul 10, 2014, at 6:08 AM, Adam Dershowitz Ph.D., P.E. <dersh at alum.mit.edu> wrote:

> 
> 
> On Jul 10, 2014, at 1:41 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
>> 
>> On Jul 9, 2014, at 11:01 PM, Adam Dershowitz <dersh at alum.mit.edu> wrote:
>>> 
>>> No. They do use existing standard ports. So openmodelica does require certain macporys dependencies, not its own separate copies. I don't know about Qt, and don't have access to check at the moment. But, my guess is that they are using the standard macport Qt, not a redundant one. I know that for a bunch of other things they just use the macport port so there is no redundancy. They have even worked on some ports to get them upgraded to get things to work together. The only reason that I could see any redundant versions is if they require some specific version that macports doesn't have. And doing that would be tricky to avoid any conflicting versions.
>>> I think that you have a bit of a misunderstanding. You could, for example create your own port file of something, and just keep that file locally (see the macport instructions). That port could then have other dependencies that are included with macports. All they have done is put their port file, instead, on their server, and you can then use it by adding it to your sources file. No redundant files involved, and no extra disk space. A port file is just a text file that explains where to find files, and how to build. Part of that "how" is what other ports are required to be installed. If someone were able to copy the current port file from their server to macports the build would be identical in size and dependents.
>>> My guess is that the reason they haven't done that is because the release version is a bit behind, and the develop version is changing every day. But I don't know for sure.
>> 
>> Adam, Jerry is correct. The binary distribution provided on the openmodelica web site, though created with MacPorts, installs the MacPorts-provided dependencies into a separate prefix /opt/openmodelica, not the normal MacPorts prefix /opt/local. This is exactly as we at MacPorts would recommend for a third party wanting to distribute a standalone installer so that it will not conflict with an existing MacPorts installation. Jerry is correct that, would the openmodelica developers instead submit their portfile to be included in the standard MacPorts ports tree, then openmodelica could be installed by using existing MacPorts dependencies (in /opt/local or whatever the user's prefix is), and would not need separate copies thereof in /opt/openmodelica. The user can already accomplish this however by setting up a second sources entry in their sources.conf pointing to the openmodelica rsync server, which is in fact what Jerry had done and is what prompted him to begin this thread, when the openmodelica rsync server was temporarily offline.
>> 
>> You can read more about all of this at:
>> 
>> https://www.openmodelica.org/index.php/download/download-mac
>> 
>> 
> 
> 
> Perhaps we just were not communicating clearly.  I was not talking about the binary, and I didn’t think that Jerry was either (perhaps I am mistaken).  He was suggesting that they make an “official port file”  and they already have one.  They just keep it on their own server.  The instructions on that page make it clear, as you said.  The reason that I believe the binary had nothing to do with Jerry’s comments is because if he was using the binary he would not have run into the rsync problem when their server went down.  That problem was purely from trying to download the source port file, which, as I have said, takes up the same amount of space whether on their server or the macports server.
> I did verify that their port does just use the existing qt4-mac port, for example, so their is no redundancy in Qt, as Jerry had suggested.  But, I do understand that if someone installs the binary, then they are not using Macports for the install, and will be downloading a whole bunch of stuff that they might already have.  
> The port file for openmodelica-devel changes many times a day.  So, I assume that they have a script that auto generates it, on their server, for every change in their development branch.  I have been using their development branch with macports, for a while now, and it has tended to work well.  As it is devel, there are occasional problems, but they have always been very quick to fix them, and keep it building.  


Well, let's all agree that I barely know what I'm talking about. 

My file at /opt/local/etc/macports/sources.conf contains two non-comment lines:
  rsync://rsync.macports.org/release/tarballs/ports.tar [default]
  rsync://build.openmodelica.org/macports/

I don't know how the second line appeared since I _think_ I have not messed with openmodelica since last installing MacPorts. Should I remove the second line?



The following is a history of openmodelica wrt Macports on my machine. I suggest that you skip it.

So let me take another crack at what I experienced 2+ years ago. I'm reconstructing and vastly simplifying from notes and forum posts.

In September, 2011, I downloaded from openmodelica.org a .pkg or .mpkg which they referred to as a binary installer. I did not have MacPorts installed at the time. It created /opt/openmodelica (I had no /opt at the time) containing 631 MB. The installer screen had a message, "This package was made with MacPorts. http://www.macports.org". Some executables were also installed in /Applications/MacPorts/ but I don't know how large it/they were.

In April, 2012 (yes, I keep notes of unusual software installations), I tried to install MacPorts, specifically py-spyder. The attempt failed, with:

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 pointed to 

   /opt/openmodelica/Library/LaunchAgents/org.freedesktop.dbus-session.plist 

This effort and related discussions continued in several ways for several days until the openmodelica guy started suggesting arcane ways to overcome the problem and MacPorts people suggesting removing openmodelica in order to succeed with py-spyder.

At one point, the maintainer at openmodelica.org said, "...If you'd like to maintain OpenModelica on macports.org, feel free. It's too much work for me (I won't accept to maintain the horrible paradiseo and rml-mmc dependencies on macports)."

In August, 2012, I noted to myself that I had grown weary of the process (and never got openmodelica to run). I noticed that Wolfram was offering a version of OpenModelica called SystemModeler that is integrated with Mathematica, so that seemed like a relatively good approach even though I'm a self-funded researcher and it was $ off my beer budget. I believe that the Wolfram product uses an old version of openmodelica and they don't like to upgrade stuff frequently (or even issue bug fixes but that's another matter).

Jerry