MacPorts and Summer of Code - first steps
Jordan K. Hubbard
jkh at brierdr.com
Fri Mar 2 00:32:21 PST 2007
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
More information about the macports-dev