Binary package installation without Portfile

[Craig Hughes]

Hi folks,

I'm trying to build a package of my own for distribution to folks who use MacPorts.  I do not want to put the port into the official ports tree (it's a commercial product).  I've built a Portfile in my own overlay ports tree, and on my local machine I can port build/port archive/port dmg, etc.

Now.  Having built on my local machine, I want to take a built package, and send it to someone else, so they can install it.

Option 1: port mpkg/mdmg
------------------------

My package depends on a ton of stuff, which in turn depends on more, etc.  port mdmg produces a disk image which is about 400MB in size (including all the shared libraries etc that the thing needs, plus all the docs etc for those too).  There seems to be some bug too where pango isn't packaged correctly, and Python2.6 just fails to install, so this is not currently working; I'm trying to tweak this to get it working, but it looks like it's probably not gonna provide me a lot of flexibility.  One nice advantage is that folks don't need to have MacPorts installed for this to work though, if it works.  But if the *do* have MacPorts installed, then actually it'll kind of mess stuff up, cos the pkg will install stuff into /opt without telling ports about it, possibly nuking stuff that ports actually installed there itself.

Option 2: port archive
----------------------

I built my package, and made the archive.  The tarball is in /opt/local/var/macports/packages/darwin/x86_64/packagename-version_0.x86_64.tgz -- inside the package is a copy of the portfile.  I copy this tarball to another machine with a clean install of MacPorts on it.  I try port unarchive packagename, and it says "no such package".  Do I need to have the Portfile installed on the target machine in order for it to even look for the binary package?  It's not going to see the appropriately-named tarball there and then try and grab the Portfile from inside it?  The downside of this method is that even if it did pick up the portfile from inside the tarball, it's going to then need to build & install all the various dependencies.  The upside is that if the person already has macports, it's not gonna clobber that.  Either way though, the instructions for a user to actually install the thing are ridiculously complicated "as root, edit macports.conf in some obscure directory to turn on archive mode, then copy this file to some magic directory 9-levels deep in /opt, then run port install packagename", and that's only if it reads the portfile from within the tarball, which is apparently doesn't.  So I'll have to also explain to them how to create an overlay tree, install the package portfile in there, then do the other steps.  And if they mess that process up in some way, it won't work....

Option 3: regular tarball archive
---------------------------------

I could also do something where I take my package and just bundle it up as a regular tarball (not necessarily from /opt), and then include instructions to the effect of:
a) install macports
b) port install <list of dependencies>
... wait a few hours ...
c) untar my tarball and run the exectuable

This has the advantage that it'll work for existing macports users, doesn't require editing config files, and it should work.  It has the downside that for non-macports users or macports users who didn't already have all the dependencies built & installed, it will take a LONG time to install.


So my basic question:  How can I easily distribute a binary package which I built using macports which depends on ports-generated shared libraries, in a way which will work for folks whether they have or don't have macports, but which doesn't require them to have a PhD in macports config file editing?

Is there some clever way I'm overlooking?

Thanks

C