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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
