chroots for testing other OS versions (was: buildbot errors)

[Joshua Root]

On 2011-11-18 10:37 , Jordan K. Hubbard wrote:
> 
> On Nov 14, 2011, at 12:39 PM, Ryan Schmidt wrote:
> 
>> I think it would be astronomically difficult to get anything like that
>> working on OS X. We can't even get a chroot at all working on Snow
>> Leopard and up; other MacPorts developers have tried that and failed.
>> That's why the buildbot doesn't run in a chroot. Getting a chroot,
>> plus making it believe it was an earlier version of the OS than it is,
>> with the corresponding required version of Xcode that only runs on
>> that earlier OS, sounds impossible to me. It would be much easier to
>> run an entire earlier version of OS X in virtualization.
> 
> Really?  You've given up on darwintrace so easily? :-)
> 
> I don't know what attempts you've made to simulate a chroot environment
> with it, but we had pretty good success doing that (and "faulting in"
> dependencies as we went, including the base OS bits themselves)
> with darwinbuild <http://darwinbuild.macosforge.org/> (from which the
> original darwintrace comes).  I know that the crappy buildall shell
> script I wrote used chroot and mounted disk images to build things in a
> clean environment each time, but I also learned how incredibly painfully
> slow that was and prone to error.  If I had it to do over, I would
> definitely go the "simulated chroot" route, and probably (in this case)
> also allow the user's system bits to be a source location for faulting
> stuff in as an option, assuming the user could also make some reasonable
> assertions about how clean their host environment was.

There's certainly a lot more that could and should be done in the realm
of trace mode and sandboxing. The problem with an actual chroot is
mainly that modern OS X relies on a lot of sockets to get anything done
(DNS lookups was the one that stopped me going down that path).

Running all the bits from an earlier OS version though? Not so sure.
You'd have to use the current libSystem so it matches the kernel
interface. Then hope nothing needs undocumented/private features of the
old libSystem.

But I guess we don't know for sure until someone tries it...

- Josh