On June 29, 2005 05:50 pm, Banginwar, Rajesh wrote: > As part of LSB standardization process, we look at the interfaces and > corresponding data types and make it part of the specification. If the > data types are expected to change and the interfaces do not hide them, > then that part of the library may not be a candidate for LSB.
Well there are two things that spring to mind. 1. Most "use" of openssl, at least as might be considered useful from an LSB-perspective, is of the SSL layer itself (libssl). This requires the direct use of certain APIs in the underlying libcrypto layer too, but AFAICT these would be easier to standardise on than the full set of APIs and are probably more ABI-friendly (ie. loading and initialising RSA/X509 objects, etc). NB, that's a cursory thought, I've not attempted to dig terribly far on this. 2. This is a refined variation on the issues distributions already face when distributing openssl in shared-library form and maintaining classes of applications that have dependencies on these libs. The consensus seems to be to use versioning to manage this, where a system can have multiple openssl libraries installed of differing version levels. Eg. 0.9.6, 0.9.7, etc. Bugfix releases to individual versions are expected to maintain binary compatibility, or distributors at least Q/A this at their end and patch around any issues as/where necessary. You'd have to check with the distributions themselves to know more though, that's out of our hands. Mark, any comments from a Redhat perspective? The reasons Steve outlined cover why we can't provide assurances about full ABI compatibility (nor even API compatibility) in a long-term sense. To do so would take a lot of undesirable but legacy aspects of the toolkit and fix them in place. However, the unwritten rule is to ensure that each incremental(/"bugfix") release of a given stable branch does preserve binary compatibility, and incorporation into LSB definitions would obviously go a long way turning this into a firmer commitment. Note also that major releases, which we freely admit can break ABI and/or API compatibility where required, are made far less frequently - as a perusal of release history will aptly demonstrate. I should also mention that we're not making vast overhauls of APIs on a regular basis, nor for the mere fun of it, so if adaptations are required long-term to allow future LSB revisions to incorporate newer release levels, this would hardly involve major surgery. Perhaps that's an avenue until such time as openssl does get to some kind of 1.0 plateau. Hope springs eternal. [ Or people wanting LSB compliancy can always statically link any version of openssl they like, but I guess that's not what you're after :-) ] Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.openssl.org/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
