John Plocher wrote: > Bart Smaalders wrote: >> Please describe how a FOSSS project would deliver a new, incompatible >> version of a library used by multiple FOSS "things". Take as an example >> rev'ing OpenSSL. > > Designing on-the-fly: > > The OpenSSL team would deliver a new versioned binary package > into the "bleeding edge" repository.
I know you mean that as an example but OpenSSL is probably the single worst example you could have picked :-) > The ON consolidation's security team would react to the availability > of a new OpenSSL by installing it, testing it, fixing the interactions > that broke with it, etc, iterating as needed with bug reports to the > OpenSSL team and a stream of updated bleeding edge versions. Once > things "worked", a new version of ON would be pushed to the bleeding > edge repository and the recipe for building an ON-based distro would > be updated to reflect the new OpenSSL version. > > This is effectively what is done today at the source code level, > but with OpenSSL copy/pasted into ON's source tree. Actually not quite. OpenSSL is compiled 5 times in ON: i386, amd64, sparcv7, sparcv9, stand for wanboot. The standard OpenSSL makefiles don't provide the ability to that. OpenSSL in ON isn't yet vanilla OpenSSL from openssl.org (it is patched - less that it used to be but it is patch) because of its use by wanboot in the pre kernel environment. Until that can be resolved by updating wanboot to do something else or by having some other consolidation build OpenSSL suitable for wanboot (which I doubt since it is tricky enough to do in ON never mind out of it) OpenSSL can't be anywhere but ON. I wish (oh how I wish!) that I had done thinks differently when I was advising the wanboot team and when I first integrated OpenSSL (but that was all prior to the rampup of the SFW consolidation). Anyway none of this is really relevant to this case. -- Darren J Moffat
