Bugzilla Bug 152706

- it uses libpcre of the system 
- same bugs from debian
- and use correctly USE of mbox

Created an attachment (id=100422) [edit]
exim-4.63.ebuild.diff

Created an attachment (id=100423) [edit]
30_dontoverridecflags.dpatch

Created an attachment (id=100424) [edit]
36_pcre.dpatch

Created an attachment (id=100425) [edit]
37_upstream-patch-384015-add_headers.dpatch

Created an attachment (id=100426) [edit]
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.