GSoC idea for the binary issue (yet again)

[Dan Ports]

On Sun, Mar 27, 2011 at 08:44:23PM -0700, Jordan K. Hubbard wrote:
> > The first issue is that a command for installing binaries without requiring Xcode or the ports tree is wanted, so that users can easily install binaries without needing a whole bunch of dependencies. The suggestion is to create a new command, which is what I want to do during the summer. This command, let's call it pkg, will install binaries only, without the need for the whole ports environment (ports tree and Xcode, but still registry and TCL).
> > 
> > Note here that a TCL interpreter is still needed because of the scripts in the Portfiles! There are as I see it 3 options. 
> 
> There are a lot of things you seem to be doing to avoid installing a copy of Ports, when I actually have to wonder why this is so important.  The entire "ports tree", if you don't actually include the build recipes in dports, is less than 10MB.  You could simply depend on this being in a port-1.0 package which could be installed as a dependency if the user does not already have MacPorts installed on their system.  Once you can assume that /opt/local contains the MacPorts distribution before your first post-install / post-activate rule will ever run, it makes things a lot simpler IMHO.

Actually, it sounds like he's not avoiding it at all, and indeed is 
installing the MacPorts TCL libraries and using them to evaluate
post-activate rules from the portfile.

I agree that this is a totally reasonable approach. The main benefits
I'd want from binary packages are
  - not having to wait while eveything compiles (large packages like
    qt4-mac come to mind!)
  - not having to install build-time dependencies (it is silly to have
    to install all of texlive to build the documentation to some random
    package)
  - not having to have Xcode installed
...and in comparison to those the question of whether we have to install
TCL and 10MB of libraries seems a non-issue.

Really, I would even be OK with a system that required people to have a
copy of the ports tree around, but that seems like it's easily avoided
by storing a copy of the appropriate portfile in the package.


> > I would implement a pkg(1) command in Objective-C using MacPorts.framework to interact with the registry.
> > The command would fetch archives and their belonging Portfile, unarchive it at destroot and run the scripts in the Portfile using a TCL interpreter (but still without need for the ports tree or Xcode).
> 
> I think that's a perfectly reasonable thing to do, especially as it will ensure that MacPorts.framework is exporting all of the "right API"  in terms of how you can drive it to build packages on demand or register things in the registry on behalf of the pkg command.  Stop me if I'm incorrect, but the registry is also only ever modified as part of installing software in MacPorts, right?  This suggests that the only thing that will ever write into the registry is the pkg command, all other parts of the system simply using the registry read APIs.

This seems reasonable to me too, although I'd wonder if pkg(1) is
going to have enough in common with port(1) that implementing them
totally separately (and in different languages) is making things
unnecessarily difficult.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/