On Aug 31, 2005, at 4:43 PM, Kevin Van Vechten wrote:

I'd like to modify DarwinBuild's behavior for downloading binaries to better support custom plists, and alleviate a lot of the server-side work that's needed to support roots downloads.

In the current scheme, each release needs to have all roots available in one HTTP directory (we use symlinks on the server side).  A better approach would be to use a search path when downloading roots.  This would allow people providing custom plists to only host the roots which they've actually modified.

Cool, this sounds good.

This scheme should work as long as all inherited builds are ABI compatible.  This is certainly true of Apple's software update releases, though it would probably be best to never inherit across major releases (i.e. 8A48 inheriting from 7W98).  Luckily major releases usually have enough differences that it wouldn't make sense to inherit in those cases anyway.

I believe this would eliminate the most common cases for using the "-depsbuild" argument.

Yes, because you essentially end up putting all the inheritance tree on the command-line in the form of depsbuild arguments... In fact we should remove -depsbuild, since it's not clear where those builds would end up in priority after you've evaluated the inheritance chain based on the database.

After this change is made, we can maintain compatibility with older darwinbuilds by adding server-side symlinks like "8C46 -> ."

Oh, you mean older darwinbuilds using the new plists, so they would request http://darwinsource.opendarwin.org/Roots/8C46/8C46/bash.root.tar.gz and get the right thing. Cool.

We may want to start putting darwinbuild compatibility versions in the plist, to indicate the minimum darwinbuild/darwinxref you need to import a plist. The sooner we do this, the easier a transition will be in the future (and the lesser support burden)

Shantonu