Mailing List Archive: exim: dev

PCRE inclusions in Exim

1 2

View All

Index | Next | Previous | View Threaded

ph10 at cus

Jun 14, 2005, 3:52 AM

Post #1 of 27 (540 views)
Permalink

PCRE inclusions in Exim

I originally built a cut-down version of PCRE into Exim because PCRE was
new and not widely available. This has now changed; quite a lot of
OS/distributions include it. In the very long term, perhaps Exim should
be changed to use a standarly installed version of PCRE.

I do *not* want to propose that at this time (especially not for a
'point release'). However, there is a halfway stage. Exim has always
included a copy of the PCRE testing program, pcretest, which gets built
alongside Exim. I suspect that very few people discover and use this
version. As part of installing PCRE 6.0[*] into Exim, it would make
things easier to drop pcretest from the Exim distribution, and simply
include the bare minimum that Exim needs.

Any objections?

Philip
-----------------------
[*] The source files have been rearranged, and are more numerous in PCRE
6.0. Several could be omitted if pcretest isn't being built.

--
Philip Hazel University of Cambridge Computing Service,
ph10 [at] cus Cambridge, England. Phone: +44 1223 334714.

exim at vorsprung-durch-denken

Jun 14, 2005, 4:22 AM

Post #2 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

Hello,

Philip Hazel schrieb:
> I originally built a cut-down version of PCRE into Exim because PCRE was
> new and not widely available. This has now changed; quite a lot of
> OS/distributions include it. In the very long term, perhaps Exim should
> be changed to use a standarly installed version of PCRE.

On FreeBSD (I checked 5.4) it's in the ports tree.

To no surprise, HP-UX does not include it on either core or apps
media or via internet express. I'm not sure, but I think I haven't
seen it on my Solaris10 box at home either.

> I do *not* want to propose that at this time (especially not for a
> 'point release'). However, there is a halfway stage. Exim has always
> included a copy of the PCRE testing program, pcretest, which gets built
> alongside Exim. I suspect that very few people discover and use this
> version. As part of installing PCRE 6.0[*] into Exim, it would make
> things easier to drop pcretest from the Exim distribution, and simply
> include the bare minimum that Exim needs.
>
> Any objections?

We usually install strictly "minimal" systems and have been happily
using pcretest that came alongside exim not only for the latter.
Well, installing it separately would be no big deal, but
nevertheless we would prefer having it available already with exim :)

Kind regards,
vt

ph10 at cus

Jun 14, 2005, 6:39 AM

Post #3 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Tue, 14 Jun 2005, V. T. Mueller wrote:

> We usually install strictly "minimal" systems and have been happily using
> pcretest that came alongside exim not only for the latter. Well, installing it
> separately would be no big deal, but nevertheless we would prefer having it
> available already with exim :)

Aha! That provides a counter-example to my assertion about pcretest. OK,
if people find it useful, then it probably makes sense to leave things
the way they are.

--
Philip Hazel University of Cambridge Computing Service,
ph10 [at] cus Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

Nigel.Metheringham at dev

Jun 14, 2005, 6:50 AM

Post #4 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Tue, 2005-06-14 at 14:39 +0100, Philip Hazel wrote:
> On Tue, 14 Jun 2005, V. T. Mueller wrote:
>
> > We usually install strictly "minimal" systems and have been happily using
> > pcretest that came alongside exim not only for the latter. Well, installing it
> > separately would be no big deal, but nevertheless we would prefer having it
> > available already with exim :)
>
> Aha! That provides a counter-example to my assertion about pcretest. OK,
> if people find it useful, then it probably makes sense to leave things
> the way they are.

Providing a build mechanism to allow exim to be built against a system
PCRE would be useful - looking very quickly at my laptop I can see at
least 6 packages using PCRE, only one of which links to the system PCRE
library.

This means that if there is a security vulnerability found in PCRE I
have 6 packages to update, whereas if everything used (dynamic linking)
the system version there would be one package to update. This is
exactly the problem which caused significant pain to people a couple of
years back when we were chasing all the packages that happened to have
zlib compiled in statically.

Nigel.
--
[ Nigel Metheringham Nigel.Metheringham [at] InTechnology ]
[. - Comments in this message are my own and not ITO opinion/policy - ]

exim at vorsprung-durch-denken

Jun 14, 2005, 7:13 AM

Post #5 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

Hello,

Nigel Metheringham schrieb:
> Providing a build mechanism to allow exim to be built against a system
> PCRE would be useful - looking very quickly at my laptop I can see at
> least 6 packages using PCRE, only one of which links to the system PCRE
> library.
>
> This means that if there is a security vulnerability found in PCRE I
> have 6 packages to update, whereas if everything used (dynamic linking)
> the system version there would be one package to update. This is
> exactly the problem which caused significant pain to people a couple of
> years back when we were chasing all the packages that happened to have
> zlib compiled in statically.

Depending on circumstances, there are good arguments both for and
against the use of [private] shared libraries. Besides, Apache and
PHP for example come with their own pcre.

So the straightest way to achieve what you're suggesting would be an
availability check for an "already-there-not-too-old" library at
pcre link time, wouldn't it?

Kind regards,
vt

ph10 at cus

Jun 14, 2005, 8:51 AM

Post #6 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Tue, 14 Jun 2005, V. T. Mueller wrote:

> > This means that if there is a security vulnerability found in PCRE I
> > have 6 packages to update, whereas if everything used (dynamic linking)
> > the system version there would be one package to update. This is
> > exactly the problem which caused significant pain to people a couple of
> > years back when we were chasing all the packages that happened to have
> > zlib compiled in statically.
>
> Depending on circumstances, there are good arguments both for and against the
> use of [private] shared libraries. Besides, Apache and PHP for example come
> with their own pcre.
>
> So the straightest way to achieve what you're suggesting would be an
> availability check for an "already-there-not-too-old" library at pcre link
> time, wouldn't it?

That is too much of an upheaval for a 4.52 release that I want to get
out soon. I have, today, modified Exim to include the new-format PCRE
6.0 file set, but it is getting messier to "cut down" PCRE for Exim
because of the new features in PCRE. Something will have to be done in
due course. One, or even both of:

(1) Insist on a system library being installed.
(2) Use a *standard* private copy of PCRE, not a cut-down version as now.

--
Philip Hazel University of Cambridge Computing Service,
ph10 [at] cus Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

jwblist at olympus

Jun 14, 2005, 10:15 AM

Post #7 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On 6/14/05 8:51 AM, "Philip Hazel" <ph10 [at] cus> wrote:

> On Tue, 14 Jun 2005, V. T. Mueller wrote:
>
>>> This means that if there is a security vulnerability found in PCRE I
>>> have 6 packages to update, whereas if everything used (dynamic linking)
>>> the system version there would be one package to update. This is
>>> exactly the problem which caused significant pain to people a couple of
>>> years back when we were chasing all the packages that happened to have
>>> zlib compiled in statically.
>>
>> Depending on circumstances, there are good arguments both for and against the
>> use of [private] shared libraries. Besides, Apache and PHP for example come
>> with their own pcre.
>>
>> So the straightest way to achieve what you're suggesting would be an
>> availability check for an "already-there-not-too-old" library at pcre link
>> time, wouldn't it?
>
> That is too much of an upheaval for a 4.52 release that I want to get
> out soon. I have, today, modified Exim to include the new-format PCRE
> 6.0 file set, but it is getting messier to "cut down" PCRE for Exim
> because of the new features in PCRE. Something will have to be done in
> due course. One, or even both of:
>
> (1) Insist on a system library being installed.
> (2) Use a *standard* private copy of PCRE, not a cut-down version as now.

I just looked at one of our servers, pcre.so is present (in the /usr tree),
but all four instances are there because of various versions and instances
of Python, and in Python-related directories, eg
/usr/lib/python2.3/lib-dynload/pcre.so

This machine has a fairly old Red Hat installation.

--John

samthecomputerman at gmail

Jun 14, 2005, 10:51 AM

Post #8 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On 6/14/05, Philip Hazel <ph10 [at] cus> wrote:
> 'point release'). However, there is a halfway stage. Exim has always
> included a copy of the PCRE testing program, pcretest, which gets built
> alongside Exim. I suspect that very few people discover and use this
> version. As part of installing PCRE 6.0[*] into Exim, it would make
> things easier to drop pcretest from the Exim distribution, and simply
> include the bare minimum that Exim needs.

I use that program for testing ALL of my regex stuff, even unrelated
to exim...but I suppose I don't need a new copy everytime exim is
built.

Sam

phil at tux

Jun 14, 2005, 12:47 PM

Post #9 of 27 (531 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

Philip Hazel wrote:
> That is too much of an upheaval for a 4.52 release that I want to get
> out soon.

Save the upheavals for 5.0 ;)

> (1) Insist on a system library being installed.
> (2) Use a *standard* private copy of PCRE, not a cut-down version as now.

Should my vote count, I vote for #1.

Exim doesn't ship with private copies of TCP Wrappers, OpenLDAP,
OpenSSL, GNUTLS, various SQL libraries or PAM. Why should PCRE be any
different?

Granted, unlike the other libraries Exim won't work without PCRE...

--

Phil Brutsche
phil [at] tux

ph10 at cus

Jun 15, 2005, 1:09 AM

Post #10 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Tue, 14 Jun 2005, Phil Brutsche wrote:

> Exim doesn't ship with private copies of TCP Wrappers, OpenLDAP,
> OpenSSL, GNUTLS, various SQL libraries or PAM. Why should PCRE be any
> different?
>
> Granted, unlike the other libraries Exim won't work without PCRE...

Yes, that's one difference. However, Exim won't work without a DB
library of some sort either... so there is at least one precedent.

--
Philip Hazel University of Cambridge Computing Service,
ph10 [at] cus Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

exim at vorsprung-durch-denken

Jun 15, 2005, 1:31 AM

Post #11 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

Hello,

Philip Hazel schrieb:
> On Tue, 14 Jun 2005, Phil Brutsche wrote:
>>Exim doesn't ship with private copies of TCP Wrappers, OpenLDAP,
>>OpenSSL, GNUTLS, various SQL libraries or PAM. Why should PCRE be any
>>different?
>>Granted, unlike the other libraries Exim won't work without PCRE...
>
> Yes, that's one difference. However, Exim won't work without a DB
> library of some sort either... so there is at least one precedent.

Err, I doubt that. At least, even an old and minimally installed
HP-UX has those included in the core OS:

$ ll /usr/lib/*dbm*; uname -rs
-r-xr-xr-x 1 bin bin 24576 Nov 14 2000
/usr/lib/libdbm.1
-r--r--r-- 12 bin bin 6272 Nov 14 2000
/usr/lib/libdbm.a
lrwxr-xr-x 1 root root 10 Oct 5 2003
/usr/lib/libdbm.sl -> ./libdbm.1
-r-xr-xr-x 1 bin bin 12288 Nov 14 2000
/usr/lib/libndbm.2
-r--r--r-- 12 bin bin 6272 Nov 14 2000
/usr/lib/libndbm.a
lrwxr-xr-x 1 root root 11 Oct 5 2003
/usr/lib/libndbm.sl -> ./libndbm.2
lr--r--r-T 1 root sys 27 Oct 5 2003
/usr/lib/llib-ldbm -> /usr/ccs/lib/lint/llib-ldbm
lr--r--r-T 1 root sys 25 Oct 5 2003
/usr/lib/llib-ldbm.ln -> /usr/ccs/lib/llib-ldbm.ln
HP-UX B.11.11

So I'd still say that pcre would be the first external prerequisite
for "core" exim if omitted from the distribution.

Cheers,
vt

ph10 at cus

Jun 15, 2005, 2:47 AM

Post #12 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Wed, 15 Jun 2005, V. T. Mueller wrote:

> Err, I doubt that. At least, even an old and minimally installed HP-UX has
> those included in the core OS:

It was certainly true in the early days of Exim (i.e. at the end of last
century) that some Linux distributions (and possibly other OS) did not
include a DB library by default. A search of the very old mailing list
archives should turn up some threads (if anyone can be bothered to
look).

> So I'd still say that pcre would be the first external prerequisite for "core"
> exim if omitted from the distribution.

Maybe today, yes, but not historically!

What I am thinking is that, in the longer term, PCRE may reach the same
status as the DB libraries.

--
Philip Hazel University of Cambridge Computing Service,
ph10 [at] cus Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

exim at vorsprung-durch-denken

Jun 15, 2005, 2:52 AM

Post #13 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

Hello,

Geraint Edwards schrieb:
> I don't think you understand what PH is saying - though you are both
> saying the same thing - in a different way.
>
> I think you are both saying that
> exim *needs* dbm to be pre-installed (or installed separately),
> and - in the future -
> exim *will need* pcre to be pre-installed (or installed separately).
>
> So the precedent for exim relying on an external lib already exists.

I don't seem to understand anything today - time for lunch! ;)

My point was: until now there is no separately-to-install
prerequisite for "core" exim (besides the compiler maybe) so far. In
other words: all that is required is provided by the core OS -
including dbm libs. I now double-checked this on a variety of OSs
and see to my surprise that on [Free,Open]BSD, only dbm headers are
present and libraries are required to be installed separately.
Debian, HP-UX, Novell(SuSE) and Solaris have them included.

Nevertheless, having pcre omitted from the exim distribution would
result in:

- adding (not always a first) external prerequisite to exim
- change the way BSD packages have to be built
- would not help regarding the numerous other software that uses
pcre (see Nigel's post)

Therefore, this appears to be a more pcre than exim related problem.
As long as a substantiable number of OSs doesn't come with pcre
included, I'd vote for exim bringing it's own version along with it.

Probably it would in addition be a wise idea to pick up Nigel's
point, having pcre always installed "system-wide". But that's
somewhat off-topic here.

Kind regards,
vt

exim at vorsprung-durch-denken

Jun 15, 2005, 3:14 AM

Post #14 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

Hello,

Philip Hazel schrieb:
> What I am thinking is that, in the longer term, PCRE may reach the same
> status as the DB libraries.

I do hope so! As mentioned, we really like especially pcretest, and
having it split from the exim distribution would "loose us an egg
from the basket".

Maybe we should start lobbying for pcre becoming a core-OS component
:) Especially FreeBSD would make a good candidate IMHO. From about
90 servers here, there are exatcly zero that don't use regexps here
and there.

Until this world has become a better place, I would again politely
ask for pcre sticking with exim, saving us a lot of extra work.

Cheers,
vt

Nigel.Metheringham at dev

Jun 15, 2005, 3:18 AM

Post #15 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Wed, 2005-06-15 at 11:52 +0200, V. T. Mueller wrote:
> Nevertheless, having pcre omitted from the exim distribution would
> result in:
>
> - adding (not always a first) external prerequisite to exim
> - change the way BSD packages have to be built
> - would not help regarding the numerous other software that uses
> pcre (see Nigel's post)

My own feeling is that I would like to have the mechanism to select at
build time the use of an internally packaged PCRE or a system PCRE.
That gives a migration path for OSes to move to having PCRE as a system
library and reducing the n copies they have across the system to just
one.

This does tend to also require that PCRE have a stable API and ideally a
way of reporting back its version number so that information can be seen
when debugging exim problems. I confess I'm currently too lazy/busy/etc
to have looked up whether these requirements/assumptions are true.

Nigel.

--
[ Nigel Metheringham Nigel.Metheringham [at] InTechnology ]
[. - Comments in this message are my own and not ITO opinion/policy - ]

lists at timj

Jun 15, 2005, 3:56 AM

Post #16 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Tue, 14 Jun 2005 16:51:24 +0100 (BST)
Philip Hazel <ph10 [at] cus> wrote:

[PCRE support in Exim]

> (1) Insist on a system library being installed.

Go for it, IMHO. As Nigel said, I'd rather have 1 copy of a library to
update in case of an important (e.g. security) fix, rather than
the lottery of trying to pin down completely unrelated packages because
they're statically linked against it. No point in having ten copies of
something on a system when you only need one. Plus it saves you having
to issue Exim updates in the event of a critical PCRE problem.

OK, so I use systems (RH/Fedora) which come with PCRE. But even for
those that don't, the above is still relevant. Even if Red Hat removed
the PCRE package from their distributions, I'd still say the same.

> (2) Use a *standard* private copy of PCRE, not a cut-down version as
> now.

Even if you opt for this, would it be possible to have a build-time
option to dynamically link against a system copy? PHP provides this
choice, which is nice. Presumably it would be fairly easy if Exim is
expecting a "standard" version anyway.

Tim

jonathan at cs

Jun 15, 2005, 6:00 AM

Post #17 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Wed, Jun 15, 2005 at 11:56:45AM +0100, Tim Jackson wrote:
> On Tue, 14 Jun 2005 16:51:24 +0100 (BST)
> Philip Hazel <ph10 [at] cus> wrote:
>
> [PCRE support in Exim]
>
> > (1) Insist on a system library being installed.
>
> Go for it, IMHO. As Nigel said, I'd rather have 1 copy of a library ...

Just to put in the counter example. I had an exim built against a system
berkeley DB library once. After one upgrade exim could no longer read
its DB files because the library had changed enough to cause a
problem. Much mail was rejected because of it.

Since then I have always built my own DB library and placed it in my
exim binary tree and linked exim against it so that when the other
admins type "yum update" there's a much reduced risk of exim suddenly
dying.

Relying on system libraries is fine as long as you can be sure that your
binary is compatible with all the point patches that will happen to the
library in the future. For something as critical as email I like to compile
my own version with only the libraries I require linked against it and with
those libraries not part of the system so they don't get updated by
automated management tools.

--
______ jonathan [at] cs Jonathan Knight,
/ Department of Computer Science
/ _ __ Telephone: +44 1782 583437 University of Keele, Keele,
(_/ (_) / / Fax : +44 1782 713082 Staffordshire. ST5 5BG. U.K.

michael at freenet-ag

Jun 15, 2005, 6:34 AM

Post #18 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

> > > (1) Insist on a system library being installed.
> >
> > Go for it, IMHO. As Nigel said, I'd rather have 1 copy of a library ...
>
> Just to put in the counter example. I had an exim built against a system
> berkeley DB library once. After one upgrade exim could no longer read
> its DB files because the library had changed enough to cause a
> problem. Much mail was rejected because of it.

I am aware of that discussion since SunOS 4, and it probably existed
before. It's not one question, but two: Included or system-wide
installation? Static or shared library?

If done right, a system-wide shared library is great. From personal
experience, Sun let me have that joy: Whenever the API changed, they
increased the major release and everything kept working. Almost any
open source project screwed it up at least once, and some for every
other release. Some even break the API from release to release so that
even recompiling does not help.

I don't have PCRE installed on any system I run, probably because POSIX
regular expressions always sufficed for me. But I think Nigel is right.
Included libraries usually make the installation much easier, but that's
no excuse not to do things right, and dependencies do not have to be as
bad as they usually are.

If you are afraid of a PCRE upgrade screwing your system, link Exim
against its static system-wide version. That's what I do with Berkeley DB
and OpenLDAP for good reasons. I don't see why Exim should include its
own copy, if it does not contain patches specific to using it with Exim.
Even with a static library, I just have to link software against it,
instead of having to update package sources in case of emergency upgrades.

I do have one wish, though: Please include a file called DEPENDENCIES or
something like that, with a description of all libraries: their name,
required or optional, a version known to work, a suggestion for static
or shared linkage, one or two sentences what they do and the URL of
their home page. It may set new standards for open source projects,
in particular if that information is kept up to date. :-/

Michael

ph10 at cus

Jun 15, 2005, 8:21 AM

Post #19 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Wed, 15 Jun 2005, Nigel Metheringham wrote:

> This does tend to also require that PCRE have a stable API and ideally a
> way of reporting back its version number so that information can be seen
> when debugging exim problems. I confess I'm currently too lazy/busy/etc
> to have looked up whether these requirements/assumptions are true.

They are.

--
Philip Hazel University of Cambridge Computing Service,
ph10 [at] cus Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

ph10 at cus

Jun 15, 2005, 8:23 AM

Post #20 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Wed, 15 Jun 2005, V. T. Mueller wrote:

> Until this world has become a better place, I would again politely ask for
> pcre sticking with exim, saving us a lot of extra work.

I am making no change (other than moving to PCRE 6.0) for the next Exim
release.

At some time in the future, a good move might be to do the work to allow
for selection of system vs private PCRE. At that time, I would change
the private PCRE to be a "standard" rather than a cut-down version.

--
Philip Hazel University of Cambridge Computing Service,
ph10 [at] cus Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

ph10 at cus

Jun 15, 2005, 8:24 AM

Post #21 of 27 (531 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Wed, 15 Jun 2005, Tim Jackson wrote:

> Even if you opt for this, would it be possible to have a build-time
> option to dynamically link against a system copy? PHP provides this
> choice, which is nice. Presumably it would be fairly easy if Exim is
> expecting a "standard" version anyway.

The only thing "non-standard" about the version of PCRE that is included
in Exim is that it includes only those functions that Exim uses, and not
those that it does not. And Exim compiles it without UTF-8 support, but
that is a standard option.

--
Philip Hazel University of Cambridge Computing Service,
ph10 [at] cus Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

ph10 at cus

Jun 15, 2005, 8:26 AM

Post #22 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Wed, 15 Jun 2005, Michael Haardt wrote:

> Almost any open source project screwed it up at least once, and some
> for every other release. Some even break the API from release to
> release so that even recompiling does not help.

Such as BDB, who have just broken things again by changing the API at
the 4.3 release. This is not the first time. Sigh.

> I do have one wish, though: Please include a file called DEPENDENCIES or
> something like that, with a description of all libraries: their name,
> required or optional, a version known to work, a suggestion for static
> or shared linkage, one or two sentences what they do and the URL of
> their home page. It may set new standards for open source projects,
> in particular if that information is kept up to date. :-/

I am afraid that is not a wish that I will ever have time to fulfil.

--
Philip Hazel University of Cambridge Computing Service,
ph10 [at] cus Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

msherman at projectile

Jun 15, 2005, 9:02 AM

Post #23 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

Philip Hazel wrote:
>
> I am making no change (other than moving to PCRE 6.0) for the next
> Exim release.
>
> At some time in the future, a good move might be to do the work to
> allow for selection of system vs private PCRE. At that time, I would
> change the private PCRE to be a "standard" rather than a cut-down
> version.

It's worth noting that in the Debian distro, exim appears to link to a
shared libpcre package, so you may want to grab diffs from the debian
package. Marc Haber, can you confirm this?

- Marc

lists+exim-dev at adam-barratt

Jun 15, 2005, 9:19 AM

Post #24 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

On Wednesday, June 15, 2005 5:02 PM, Marc Sherman <msherman [at] projectile>
wrote:

> Philip Hazel wrote:
[...]
>> At some time in the future, a good move might be to do the work to
>> allow for selection of system vs private PCRE. At that time, I would
>> change the private PCRE to be a "standard" rather than a cut-down
>> version.
>
> It's worth noting that in the Debian distro, exim appears to link to a
> shared libpcre package, so you may want to grab diffs from the debian
> package. Marc Haber, can you confirm this?

debian/patches/36_pcre.dpatch :-)

Once you remove the dpatch wrapper, it's the grand total of 25 lines of
unified diff

Regards,

Adam

exim-dev at cox

Jun 15, 2005, 10:23 AM

Post #25 of 27 (530 views)
Permalink

Re: PCRE inclusions in Exim [In reply to]

Philip Hazel wrote:
>
..[snip]...

After reading the whole debate on static/shared/blah blah blah...

>
> At some time in the future, a good move might be to do the work to allow
> for selection of system vs private PCRE. At that time, I would change

This is the easiest way to do things I think, and it makes all involved
happy does it not? I know I am for choice myself. Leave the
default to the included version, but allow for the choice of another.

> the private PCRE to be a "standard" rather than a cut-down version.

Is there some reason that the "standard" version cannot go out
today??? It does not break anything when it has the other support
such as UTF-8 etc. does it??

I am all for not compiling things you do not need, but in this case,
(without going over all the differences between the cut-down and
"standard" versions) does it really matter?? Also, with some of the
MIME checks that can be done now, UTF-8 support for the RX may be
very usefull ;)

--

--EAL--

--

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads