deploying pre-build ports with macports

[Anders F Björklund]

Boyd Waters wrote:

>> 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/?

None of the binary packages (pkg, rpm, deb, etc.) will write receipts.
The binary archives (tgz, tbz, xar, etc.) however, will work as ports.
What makes matters *really* confusing, however, is that the "archives"
used to be called packages in FreeBSD Ports and are stored in packages:

/opt/local/var/db/dports/packages  (need to set: "portarchivemode yes")

> 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.

"port pkg" creates Mac OS X packages, rather than MacPorts packages.
And the old command of "make package" is now "port archive" instead.

> 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.

You can't build off the binary packages, you will need ports/archives
for that - or else you also need to build any new ports as .pkg too ?
(i.e. they could install a "fortran-thing" package along with the
"fortran" binary package and those two would then work together...)

But you cannot mix and match ports/archives and the binary packages.
Even if MacPorts creates them, those packages are for "outside" use.

> 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.

I think this one is a "feature" of the Mac OS X Installer.app, though ?
(Just like the missing "Uninstall" button, for .pkg already installed.)
Some of the reasons why I would recommend using RPM over PKG, actually.

But I did think later versions of PackageMaker.app fixed the bug above ?
i.e. by automatically moving any /etc/ files into /private/etc/ instead.
(also, having wrong permissions on / was another way to hose a 
system...)

> 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.

If you want your users to be able to use "port" themselves, then you
should probably use the archives. If you plan on building it centrally
and then distributing the binaries, then you should use the packages.

This will work better when the Remote Fetching feature is implemented...
Then the MacPorts port command or the Package Manager* will try to fetch
pre-built binaries from a server, before starting to do a source build.

* such as e.g. the Smart Package Manager, for handling RPM packages

--anders