Re: [exim-dev] GnuTLS status

On 2012-05-21 at 09:48 +0100, Dr Andrew C Aitchison wrote:
> Hmm. I suppose that Red Hat *is* like Debian.
> RHEL 5.8 has gnutls-1.4.1 and RHEL 6.2 has gnutls-2.8.5.
>
> I know sysadmins who still consider RHEL 6.2 a bit experimental
> for production servers.

If GnuTLS doesn't work, they have OpenSSL. As long as one or the other
works, they should be fine. I suspect that those sysadmins are sticking
with vendor packages, so it's RedHat's problem to manage packaging of
Exim.

If someone is maintaining Exim separately (because it's a mail-server
and they don't use vendor packages for the primary purpose of the
machine, to stay current on that), *and* they have library issues, then
I suspect that they are on an OpenSSL system and installing a different
GnuTLS will only affect Exim.

Failing that, use a differently named pkg-config file for their GnuTLS
install, which sets RPATH and forces Exim to use their install. Or
similarly for OpenSSL.

There are many ways to manage getting current software to run on old
systems and I'm willing to apply reasonable patches to support those
systems. Have done, even as part of this release series.

What we can't do it refuse to ever use a newer version of a library.
And if the library changes APIs, we have to make some choices.

For libraries with a light binding, we can have both APIs. Eg, ClamAV,
where we still have WITH_OLD_CLAMAV_STREAM to support the older API.

For libraries with tighter bindings, I'm likely to again choose to do
what I did with GnuTLS: pick the version which is bundled with a
selection of current OSes, avoid the newest one (GnuTLS 3), and work to
make sure that we can go back a few versions. Exim builds now with 2.8,
2.10, and 2.12. It might build with some older version, and if not, but
it's a *light* patch to do so, I'll probably apply it.

Life is a balance of order and chaos, stasis and change. We can't lock
onto the old API and never update. We have to move forward, carefully,
and make sure we keep putting ourselves in a position where we *can*
move forward. When the vendor of a library starts issuing warnings
about your usage of the API, you're in a dead end and you need to
change. Or look at using a different library, leaving that one as the
historic deprecated choice.

I almost provided both the old and new GnuTLS bindings, but decided it
would add more complexity to configuration than benefit, and it kept me
from cleaning up some internal API work. Also, it would place all the
cost on the volunteer maintainers, and ~none of the benefits.

Which leads to the point that none of the current maintainers are paid
to work on Exim, whereas the commercial OS vendors do pay people to
maintain their packages, so by moving onwards we place the cost burden
on those people being paid for their ability to maintain a stasis. So
ultimately, if this really is a problem and then the cost structures are
already in place to support a solution.

-Phil