MacPorts and Summer of Code - first steps

[Jordan K. Hubbard]

First, I think this is a great idea and thanks go to whomever  
suggested it - MacPorts is full of the sorts of projects that summer- 
of-coders could do in the time allotted.

Second, before google is even approached I think the project needs to  
pull a wish-list together and demonstrate that it's not just looking  
for some free labor to get a bit of grunt work done, it's got some  
project ideas that will really move the project forward and  
demonstrably improve its utility to the Macintosh community at  
large.   I've been one of the google SoC mentors (for FreeBSD) and I  
can say that the project ideas which tend to get funding aren't the  
ones which go "clean up our man pages and look for typos", they're  
more along the lines of "port ZFS to FreeBSD".

Furthermore, I *know* that MacPorts has a number of long-stalled  
efforts in base/ which are just waiting for someone to go dive on  
them single-mindedly.  Just thinking right off the top of my head,  
some of these are:

1.  Finish the work Paul Guyot started with the trace code and create  
real "virtual chroot" environments for building ports, constraining  
what their configure scripts can see and validating that their  
explicit dependencies are correct and fully-formed.

2. Working in concert (or cooperatively) with whomever does #1, get  
package building working all the way to a point where complete  
package builds can be done for all of MacPorts and the results made  
available to users as pre-build package collections.

3. Come up with a front-end for installing packages (or building  
ports, where no package exists) for naive end-users.

4. Take what Will started with the notion of a depot location vs an  
installed location (e.g. /opt/local/var/db/dports/software/gawk/ 
3.1.5_2/opt/local/bin/gawk vs /opt/local/bin/gawk) and finish the  
job, making depot-to-depot dependencies finally work.  That is to say  
that if port foo depends on version 1.2.3 of port bar, it should be  
compiled and linked in such a way that it's wired to the depot  
location of bar, not the "activated" location.  That will finally fix  
the fragility problem where deactivating port bar vers n-1 in order  
to install port bar vers n (because other things depend on n) won't  
also require breaking everything that relies on n-1.

5. Sweep through all Portfiles and look for useful opportunities to  
add more built-in Tcl functions that make Portfiles more (usefully)  
terse, powerful, flexible or easier to write.  I'm sure there is an  
entirely family of helper functions yet to be written here.

That's just 5 off the top of my head with about the same number of  
minutes work devoted to pulling them out of my memory.  I know that  
I've seen easily 10 times that many "good idea, someone should do  
that!" emails fly by the lists over the last few years too, so I'm  
sure others can easily add to this list.

Approaching google is also something that shouldn't be done ad-hoc by  
a number of people all claiming to represent macports in some way.   
Someone wearing the portmgr mantle needs to collect all these ideas,  
get some democratic input as to which ideas are truly the best, then  
approach google with the list and try to get added as a SoC project.   
They need to do it quickly too since we don't have much time.  I  
nominate jmpp.

- Jordan