MacPorts AutoBuild

[Bryan Blackburn]

On Jun 20, 2008, at 1:28 PM, Jordan K. Hubbard wrote:
>
...
> Of course that simply never happened, at
> least not beyond my own primitive attempts, all of which yielded such
> terrible results [>50% failure rates] that I came to have dark
> suspicions about my methodology for creating the build chroot (as well
> as dark suspicions about how many of our ports actually build at any
> given time) and went on to other things.
>

While what I've written does have some of it early lineage from your  
buildall.sh script, it's definitely changed a bit.  The good news is  
that of the 150+ or so ports I had MPAB try to build here, a vast  
majority of them built successfully.  The failures were all  
explainable at the MacPorts level, not MPAB (eg missing distfiles, a  
perl module needing 'port -f install', and so on).

> Anyway, if MPAB/MPWA are starting to generate good results on whatever
> development hardware is being used, and by "good results" I mean all
> of the below:
>
> o	Building, or at least iterating through, all the ports in the system
> and generating helpful status information for each (even if it's
> "falls over immediately", that's good to know)
>

MPAB currently builds the list of ports to attempt by sorting them by  
dependency: the early ones it builds are dependencies of later ones.   
The reason for this is that if Y depends on X and X failed, it'll  
simply skip Y.  Also, of course, if X did build successfully, all  
other ports depending on it will simply cause X do install from the  
portarchive instead of rebuilding again.  If you extract the MPAB  
tarball, the chroot-scripts/genportlist.tcl is the script which builds  
this initial list.

> o	Taking at least some pains to isolate the build products from the
> builder host machine, both in files read and files written.
>

It's a chroot, so other than the initial building of the chroot, the  
host machine's files should be left alone.  Of course, the bad thing  
is chroot needs root to run...

> o	Has had all reasonable precautions taken after doing a reasonably
> pragmatic analysis of the security implications of executing all that
> open-ended Tcl code and how a "rogue port" might attack the builder,
> either deliberately or through carelessness.
>

The biggest issue here is breaking out of the chroot, otherwise if  
something malicious happens then all future build attempts would most  
likely fail quite spectacularly.

Bryan


> Then I'd say it's time for us to start thinking seriously about
> putting this into early production.   This is the same checklist the
> project is going to have to go down before anyone will be willing to
> even "BETA" this on more private hardware anyway, so I don't think
> it's an unreasonable one.
>
> - Jordan
>