On Mar 31, 2008, at 7:32 PM, Guido Soranzio wrote:
There is no coherency in how the dependencies are expressed in
MacPorts at the moment: some ports lists all the dependencies
recursively while other ones limit to list only their direct
dependencies, as garnome and jhbuild do the right way.
This is a mess. If we had some simple tools like a buildbot or some
"bulk" scripts like NetBSD's pkgsrc, the committers could
automatically upload a report listing the packages that they already
succeeded in building and the broken ones that they couldn't upload
into their open repository.
Well, let's also be careful not to conflate multiple, desirable goals
here - that only increases the size of the task and the attendant risk
of seeing nothing happen. History suggests that people tend to run
away from large problems in this project. :-)
First goal:
Make it possible to batch build the entire ports collection, port by
port, on a carefully configured machine, spitting out consistent
(machine-parseable) diagnostics along the way.
Metrics for success:
Someone with a comparatively beefy XServe and attached RAID system is
able to build the entire ports collection from top to bottom and
deliver an initial matrix report of what ports failed and why.
Second goal:
Do a "lessons learned" assessment of the first goal and use it to
polish the batch build infrastructure to the point where it can be
moved to a more official buildbot machine.
Metrics for success:
Buildbot is up and running, with one or more automated web status
pages providing concise summaries of overall "port collection health"
as well as individual results for each port, similar in scope to http://portsmon.freebsd.org
and http://pointyhat.freebsd.org but hopefully more concise.
Third goal:
Extend the buildbot slightly to generate full packages (of some
variety) as a side-effect of the now already scheduled runs. Add some
automation to scrape the resulting packages into some globally
accessible location and extend the port machinery to make it possible
to satisfy dependencies via package as well as via port install.
Metrics for success:
MacPorts now boasts a packages collection, similar in size and scope
to that of other projects, which can also be used transparently by
both users and developers. The "port install" target no longer
actually installs bits on the target system, but rather becomes the
internal equivalent of "port destroot foo; port package foo; package-
install foo"
A suitable command-and-control GUI should also exist by this point
which provides a convenient interface to the packages collection.
So, here's the deal. If you'd like to tackle the first goal, I can be
the guy with the XServe + RAID to run the results on until the metrics
for success have been achieved. :-)
- Jordan
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
