- it uses libpcre of the system - same bugs from debian - and use correctly USE of mbox
Created attachment 100422 [details, diff] exim-4.63.ebuild.diff
Created attachment 100423 [details, diff] 30_dontoverridecflags.dpatch
Created attachment 100424 [details, diff] 36_pcre.dpatch
Created attachment 100425 [details, diff] 37_upstream-patch-384015-add_headers.dpatch
Created attachment 100426 [details, diff] 40_boolean_redefine_protect.dpatch
(In reply to comment #1) > Created an attachment (id=100422) [edit] > exim-4.63.ebuild.diff > (In reply to comment #3) > Created an attachment (id=100424) [edit] > 36_pcre.dpatch > please see bug 51257 for why this won't be used (In reply to comment #4) > Created an attachment (id=100425) [edit] > 37_upstream-patch-384015-add_headers.dpatch > (In reply to comment #5) > Created an attachment (id=100426) [edit] > 40_boolean_redefine_protect.dpatch > these patches fix what issue precisely? At the moment I'm very tempted to skip the whole bug, but I'll think about the overriding CFLAGS patch. Unless I get some feedback i'll resolve this bug and mark it appropriately within the next week or so.
=========================================== 37_upstream-patch-384015-add_headers.dpatch =========================================== Apparently a fix for bug #385 upstream: http://www.exim.org/bugzilla/show_bug.cgi?id=385 ================================== 40_boolean_redefine_protect.dpatch ================================== This defines TRUE and FALSE macros only if they're not defined someplace else. The patch here says it's present in case TRUE and FALSE are defined someplace else (like perl or some other package's header files). Not sure to what extent this is usefull though, as TRUE and FALSE should always be 1 or 0 :p
This "bug" pointed by Francisco Javier is already been used in Debian since 2002 and in my opinion is good approach. The issue is that I think is better to compile exim linking to a dynamic libpcre instead of against a static one. Nowadays libpcre is used in different projects such as Apache, PHP, KDE, Postfix, Analog, and Nmap, so if it's dynamical can be used also for the other programs, and there is no need to be replicated on the system. Another thing is that if a bug is found in libpcre then you should recompile the whole exim instead of just the libpcre, and in my modest opinion is more correct just to recompile the vulnerable library. What do you think about that? I know it's difficult to understand this from the first Francisco but I hope that this can create at least some kind of discussion. Best Regards, Roberto
I thought I'd said this before, but I can'tfind the reference at the moment, and the bug i alluded to (and the one alluded to by that doesn'thave the reply i was thinking of), I think it was in one of the security bugs, anyhow I digress, I am following the upstream maintainers on this one, I believe that the version of libpcre shipped with exim is not identical to the stand-alone one. I do not intend to patch in support for it to the ebuild. If upstream wish to separate it out, then that is their decision. http://www.exim.org/lurker/message/20040625.093645.e05aff59.en.html has Philip Hazels view. As far as I'm concerned, I will be checking to see if 40_boolean_redefine_protect.dpatch is still relevant, if so it will be patched into 4.69-r1, if not, then this bug will be closed. Cheers, Colin.
Patched 40_boolean_redefine_protect.dpatch into >exim-4.69-r1 I'm not going to be splitting out libpcre.
