Bart Smaalders wrote: > Darren J Moffat wrote: >> It is what PSARC wanted when the original case to include OpenSSL was >> reviewed. The contact is very explicit about which OpenSSL APIs we >> believe the OpenSSL community has some commitment to (the SSL and EVP >> APIs in particular). >> >> Personally I don't mind either way, however without one there is no >> comeback to the OpenSSL team if they introduce an updated version of >> OpenSSL and the build of another project in another consolidation >> starts failing. That is not to say they won't help debug the issue >> though. >> >> > > Why not place the portions of the API that you deem more stable into > a version in the library mapfile, and place the rest (unstable) in > another version?
That seems reasonable, it won't stop the breakage but at least it helps find it when it occurs and helps understand when a given application crosses the boundary. We could start by doing this only for the APIs that are in the current contracts, however ideally we would get agreement on this from OpenSSL (we did a similar thing for the MIT libkrb5 library). > Any application linking w/ OpenSSL can instantly > determine its ACTUAL usage of the APIs, and thus those apps using the > portion of the OpenSSL APIs considered stable can avoid the paperwork. > This also makes the OpenSSL team's job easier when it comes time to > change OpenSSL versions.... Feel free to log an RFE for this, but I doubt you want this case to take that job on right ? -- Darren J Moffat
