2007/609 Alpine: Mail User Agent

[Jan Pechanec]

On Mon, 22 Oct 2007, Darren J Moffat wrote:

>> > 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.

	I don't think the biggest problem is that API changes. The problem 
is that ABI changes from time to time. Dividing OpenSSL API into two parts 
won't help much; I remember just 1 or 2 const changes during the 0.9.7d -> 
0.9.8a upgrade in the whole WOS. However, when (if) we adopt 0.9.9 in the 
future we must rebuild all consumers.

	then we need that list of consumers (6 consolidations now use 
OpenSSL). I really don't think there is any sense in having an OpenSSL 
consumer without the contract *now*.

	we might have a filter library exporting just some most stable 
interfaces. That library would keep the name so no rebuilding would be 
needed - but still, the change can happen anyway and we can't do much about 
it. As already said, we would need to work with OpenSSL team on this.

>> 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....

	it would be much easier for me but quite risky for consumers. I 
remember the last time, install packages stopped working because there was 
an undocumented change inside of SSL functions (not in API or ABI) - using 
very high level interface didn't help there.

	so now, every consumers should have a contract otherwise it can run 
into troubles that we might forget about that dependency. I would be happy 
to change this situation.

	Jan.

-- 
Jan Pechanec