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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
