On 2011-01-26 at 10:07 -0600, George Kasica wrote:
> Based on the 4.747 issue with PCRE_PRERELEASE and RHEL4 how soon can we
> expect to see 4.75 come out? Curious as I have about half a dozen boxes
> here that I need to update to keep info sec happy that are currently stuck
> with that issue at 4.73....
If you want to build now, it's a *very* trivial source change. Edit
src/exim.c and remove the PCRE_PRERELEASE macro. See:
http://git.exim.org/exim.git/blobdiff_plain/88d5edb00796448347da8544088b0db1f9b61ddf..aa097c4c00f62487128d74f65c521f9e877b184f:/src/src/exim.c
May I suggest that if you have a fleet of boxes, you consider testing a
"Release Candidate" in future? If nobody with your OS tests a Release
Candidate, then problems of compatibility with your OS will arise. Exim
is maintained by a community of volunteers and those intersecting
communities who don't step up to ensure compatibility will have more
troubles than those communities that do work with us.
It looks like the dynamic module addition is causing various issues;
some inherent, in this particular case because I decided that anything
where one binary is loading other code into its address-space absolutely
had to support reporting version numbers to keep our lives from becoming
an absolute hell when people insist they've upgraded Exim but haven't
installed the modules and things fall out of sync -- the code is bound
to end up used by non-packagers, despite being intended for packagers,
so in this broader environment we need better diagnostics.
As part of this, I made Exim report compile-time vs run-time library
versions for all the main libraries I could test against (so not, eg,
Oracle). You can see this with: exim -d --version
So, since very few people tested the Release Candidate, it seems that
4.74 is having to serve as a pseudo release-candidate. This is
sub-optimal, but it's the reality we're faced with. I can't speak for
the other Exim maintainers, but my inclination is that we should give it
a week or so to shake out all the bugs that people haven't yet reported,
then do 4.75. The RHEL fix is trivial enough to apply as a build patch
that I don't see a major issue here.
Based on the reports so far, *I'm* not willing to volunteer my time to
push out a 4.75 release sooner than that. And I'm not willing to
restrict 4.75 to be bug-fixes-only -- there's one feature improvement
from the DCC maintainer which I've promised I'll commit to tree, now
that 4.74 is out.
-Phil
