Google SoC 2008

[Jordan K. Hubbard]

On Mar 2, 2008, at 4:58 PM, Randall Wood wrote:

> I would like to see MacPorts use RPM for its installation database
> instead of whatever we have now.

We don't have anything now.  We've also tried to use rpm at various  
times in the past, but the impedance matching requirements have always  
proved problematic (rpm expects its packages to be built via srpms and  
dependencies to be handled in a very specific way, just to name two of  
many).

My personal opinion is that we should start building xar files.

For the first cut, they can be essentially dumb and we can focus on  
extracting enough dependency information from them to do package  
dependency tracking.  That's pretty straight-forward and quite  
achievable with existing technology.

For the second cut, we can embed a minimal macports runtime (in the  
form of a universal dylib and some collection of tcl files) in each  
xarball, allowing us to run the same install/post-install/activate/ 
post-activate routines at install time.  A properly formed package  
represents, after all, little more than everything up to and including  
the destroot phase, archived up.  It's what to do with the specialized  
actions (add user foo, present message bar to the user, etc - just  
grep through dports looking for post-install to get a good feel for  
how varied the landscape currently is) and how to provide the same  
activate/deactivate metaphor for packages that has always held us up

Once we get to that stage, we can behead the current installation  
procedures for macports and turn that into pkg install actions.   Then  
macports just needs to carry the load up to the destroot / package  
stage and then hand things off to the package system for the install/ 
activate heavy lifting.  But, we also need to crawl before we try to  
run, which is why I think simple archives (which work for all the  
"simple" ports) is the right place to start.  Excellent SoC project!

- Jordan