[darwinbuild] proposed binary_sites change
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. Currently, the binary_sites URLs in the property lists are a base path, which DarwinBuild appends a build number to: 8C46.plist: binary_sites = ( "http://darwinsource.opendarwin.org/Roots/", ); Instead, I'd like to make the binary_sites URLs explicit for each build: 8C46.plist: binary_sites = ( "http://darwinsource.opendarwin.org/Roots/8C46/", ); The `darwinxref binary_sites` command would only print binary_sites URLs when the project being requested is actually present in that plist's projects dictionary. If URLs are printed, darwinbuild will attempt to download the root from that site. Otherwise, it will re- run the darwinxref command looking for the binary_sites property in the inherited plist. 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. After this change is made, we can maintain compatibility with older darwinbuilds by adding server-side symlinks like "8C46 -> ." - Kevin
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
On Sep 1, 2005, at 2:38 PM, Shantonu Sen wrote:
On Aug 31, 2005, at 4:43 PM, Kevin Van Vechten wrote:
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.
Good point.
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).
Good idea. Does "compat_vers" appeal to you? Monotonically increasing integer sound good? - Kevin
On Aug 31, 2005, at 4:43 PM, Kevin Van Vechten wrote:
Instead, I'd like to make the binary_sites URLs explicit for each build: 8C46.plist: binary_sites = ( "http://darwinsource.opendarwin.org/Roots/8C46/", );
I made this change for 8C46.plist, 8B15.plist, 8A428.plist, and 7W98.plist.
The `darwinxref binary_sites` command would only print binary_sites URLs when the project being requested is actually present in that plist's projects dictionary. If URLs are printed, darwinbuild will attempt to download the root from that site. Otherwise, it will re- run the darwinxref command looking for the binary_sites property in the inherited plist.
After discussion with Shantonu on IRC, I've committed some changes which differ from the above description. `darwinxref binary_sites` continues to use the standard "look in the project, then in the build" approach. If there is an HTTP error on all of the URLs provided, then darwinbuild will request the binary_sites of the inherited build, and so on.
After this change is made, we can maintain compatibility with older darwinbuilds by adding server-side symlinks like "8C46 -> ."
I have already made these compatibility symlinks. - Kevin
participants (2)
-
Kevin Van Vechten
-
Shantonu Sen