Architecture specification (was Re: [GSoC][Binaries support] Architecture)

[Jordan K. Hubbard]

On Mar 27, 2011, at 10:53 PM, Dan Ports wrote:

> I'm equally skeptical that it's possible to have a useful package
> system where packages don't have the ability to run arbitrary shell
> commands post-install. All of the major package formats I'm familiar
> with (dpkg and rpm come to mind) have this capability, and I think
> applications need this flexibility.
> 
> [ ... ]
> For me, that count also makes an argument in favor of a package format
> that includes and evaluates the TCL portfile: editing that many ports
> to put the post-activate hooks in some new format is a non-trivial
> task. Certainly not insurmountable, but given the desire to see
> binary packages sooner rather than later, I'd rather not put any more
> obstacles in the way.

Hi Dan,

I think you have grasped the problem space rather fully here.  Perhaps this would also be a good time to wind down the "hand waving" stage of this discussion (which is certainly an important part of the process which I don't mean to denigrate in any way) and start breaking the challenge down into more concrete deliverables?   In the copious 15 minutes I have between now and hitting the road for home, I'll attempt to throw out a rough outline which we can then throw bricks at:

1. Possible MacPorts deliverables
1.1.  Make sure MacPorts.framework has adequate registry APIs for an external tool to create/update/delete (CRUD) and query the registration database.
1.2.  Make a list of all rules that get run at post-install/post-activate time for a port.  You mentioned "notes", for example - when do they get displayed?  If at post-install time, then they need to be added to "the list" of stuff that pkg will want to call.
1.3.  Do we want an API for building ports tool, or is the port(1) tool already adequate for calling out to when building packages on demand?
1.4.  Investigate current Archive format:  Do archives contain all of the data necessary for the pkg command?  If not, what's missing?
1.5.  Figure out how much of MacPorts is necessary for a "minimal runtime" and package this up in a convenient tarball for the next step.

2. Possible pkg(1) tool deliverables
2.1.  Write code which can fetch an archive from a given URL (using libcurl?) on demand given some looser criteria (package name and version?)
2.1.  Write code which can un-archive an archive file and knows which +FILES to look for afterwards.
2.2.  Write code which can recursively satisfy dependency lines, using the code in 2.1 and 2.2 to fetch and extract each.
(At this point, you have most of the "dumb" parts of pkg(1) written)
2.3.   Figure out how to create a Tcl interpreter that pulls in all of the appropriate MacPorts runtime and is ready to execute rules out of an extracted Portfile
2.4.   Use this Tcl interpreter to execute all of the relevant rules, in the appropriate order, to post-install/post-activate/display notes/whatever.
2.5.   Write the appropriate information into the registry to declare the package fully installed.

Extra credit:

3.0.  Go back and hack on MacPorts such that "port install foo" becomes "port package foo -pkgFile /tmp/foo.tgz; pkg install /tmp/foo.tgz" in essence.

Yay, rough outline finished with 3 minutes to spare!  I'm outta here! :-)

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110328/d12e4de8/attachment-0001.html>