deploying pre-build ports with macports

[Boyd Waters]

On Jul 5, 2007, at 1:11 PM, Barry Wark wrote:

> Boyd,
>
> It sounds like you've been down this road already, then :)
>
>> From your answer, it sounds like things won't work. I'm a bit
> confused, though. I thought that macports would keep receipts for the
> installed ports (e.g. hdf5) (in /opt/local/var/db/dports/?) and that
> those receipts would do the trick on the client machine as well. I
> planned to compile the dependencies (e.g. hdf5) using "port install
> XXX"--a source install--, then to make an installer that has it's root
> at /opt/local and with an install target of /opt/local. Wouldn't the
> client macports still have those receipts?
>
> Sorry for my confusion.

Wow, you don't need to be sorry -- I think it is confusing.

The binary package created with "port pkg" won't write that receipt to  
${prefix}/var/db/dports/?


I'm talking about binary packages created with MacPorts -- via the  
"port pkg" command -- they cause me no end of trouble. My opinion. I'd  
like to find the time to fix the MacPorts package-creation stuff, but  
my Tcl skills may not be adequate.

Anyway. I created a large collection of packages - one for each port -  
via the "port pkg" command.

I gave these to my fellow developers, and many scientists, who also  
had Macports installed.

They double-click the pkg file, which launches the Apple installer,  
and installs the libraries, binaries, under /opt/local.

Great.

Then later they want to go build some MacPorts that need the packages  
that they've already installed with the bianry installer.

Example: I gave them the fortran compiler as a binary package created  
from MacPorts, and they want to install (from source) a package that  
needs this compiler.

When they say "port build fortran-thing", MacPorts *ignores* the  
binary-installed fortran compiler -- even though it came from a  
MacPorts-created binary package -- and goes ahead and builds every  
last little thing. Which may take hours. And may fail, depending upon  
which MacPorts tree they have.

MacPorts packages that I have created have another nasty nasty bug, in  
that they cannot handle symbolic links in directory paths. The example  
I gave earlier on this list was MacPorts emacs -- which all of our  
users assumed they needed (they don't know that OS X already has it).  
The emacs package wants to add a file to /etc/X11. But /etc is a  
symlink to /private/etc. Since the MacPorts installer doesn't handle  
that, it *deletes* the symlink to /private/etc, creates a new, blank  
directory at /etc, and then write its file, and claims that  
installation completed successfully. Rendering the Macintosh unusable  
in the process.

So I gave up on distributing binary packages created from MacPorts,  
and I just rely upon MacPorts on my developer-build box, and roll a  
tarball "by hand" for our scientific application. The tarball includes  
its own distribution of Python, Qt, etc.

Since we roll out the application to people in different institutions,  
different configurations, this is the most robust: we try to assume as  
little as possible about what might already be set up on the end- 
users' Macs.


Hope this helps! Some..

  - boyd