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