Binary package installation without Portfile

[Ryan Schmidt]

On Jun 17, 2010, at 16:22, Craig Hughes wrote:

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

Explain?

> and Python2.6 just fails to install,

Explain?

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

Yes, please do not distribute binary packages created with "port mdmg" which were created with the default MacPorts prefix. Instead, install MacPorts with a different prefix specific to your product (e.g. /usr/local/something), then build the mdmg there.


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

I don't know how archive mode is supposed to work in MacPorts so I can't comment here. I will say I agree what you've described sounds complicated so I wouldn't pursue this as an end user distribution strategy.


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

Yeah that doesn't sound ideal either.

I'd go with the mdmg strategy you showed first.

To cut down the size, you could remove documentation files, other files you don't need, etc. from each of the ports. You could keep local copies of the ports with these changes perhaps though of course then you'll have to be in charge of incorporating changes we make to the portfiles later.