selfupdate fails trying to synch with openmodelica (!)

[Adam Dershowitz Ph.D., P.E.]

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.