On Tue, May 29, 2012 at 7:34 PM, sebb <[email protected]> wrote: > On 30 May 2012 00:03, Pedro Giffuni <[email protected]> wrote: >> >> --- Mar 29/5/12, Rob Weir <[email protected]> ha scritto: >> ... >> >>> > >>> > The idea that we have remaining issues with Category-B >>> > tarballs in the tree has been around since before the >>> > release, and one of our mentors (Ross I recall) did >>> > acknowledge my point of view. >>> > >>> >>> Again, I don't see an issue here. But if you feel >>> strongly about this you are welcome to copy the >>> ext_sources over to Apache Extras and do a >>> trivial update of the build >>> script. Whatever makes you happy. >> >> I am busy at the moment, plus doing this will >> mean I have to suspend the updates I was working >> on. >> >> I think I will start next week. I will only move >> Category-B code and I will disable it from the >> buildbots too: it's rather inconvenient to have >> the buildbot depend on downloading extra tarballs. >> >> This is admittedly a stop gap solution to comply >> better with the Apache policies, the real fix would >> be to work collectively on replacing the code that >> can be replaced: > > Alternatively, it is possible to include cat B [1] dependencies in binary > form. > Is there any need to include the source? >
If the build did not consumer source then we would need to store, in SVN, category-b binaries files for each component, in each platform/architecture. That would be 4 platforms now, but I'd expect that go up to 7 in the near future. I don't think that solves any real problem. We'd still need access to the source to provide urgent security patches, etc. So we're then back to the same question: where to store the category-b source tarballs? -Rob > [1] http://www.apache.org/legal/resolved.html#category-b > >> rhino --> Google V8 >> nss --> openssl >> Seamonkey --> Mulberry library >> >> but that doesn't seem to be a priority for 4.0 :( . >> >> Pedro. >>
