On 16 Jan 2008, at 13:53, John Jetmore wrote:
> Is this a good idea? Is the motivation primarily ease of
> maintenance or
> is there perceived value to the end user? This change will
> significantly
> increase my own server maintenance and I don't even maintain that many
> servers. I love the fact that exim has always been self contained if
> desired.
Its definitely an ease of maintenance win - we don't have to track PCRE
releases (there has been another one since 4.69 came out).
I would argue its also a win for the end user/admin as they then know
that they have to maintain PCRE on a box, and if there is an issue with
that package they just need to update PCRE rather than potentially exim,
php, java...
Additionally the vast majority of exim installations I believe already
patch out the embedded PCRE and use a system one (for example this is
done on all the linux distros I have checked).
This is basically the same argument we saw 10ish years ago relating to
moving to using GIF or DB libraries rather than compiling the code into
your package.
> If there's already been a discussion of this let me know and I'll
> revie
> but I don't remember seeing it.
I have discussed this with a few people, but it was off-list. I did put
it in the 4.69 release information.
> My gut feeling is that this is related to some security fixes that
> forced
> pushing out the last release before it really had anything good in
> it and
> before the release process was streamlined, but it kind of feels
> like a
> web form that doesn't allow dashes in a credit card number - saved the
> developer 5 minutes but collectively cost the end users hours/days/
> years
> depending on how popular it is.
How many systems actually don't have PCRE available as a system library
- for heavens sake its even in Solaris (SUNWpcre package) - and they
have a 1980s runtime.
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ]
[. - Comments in this message are my own and not ITO opinion/policy - ]
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
> Is this a good idea? Is the motivation primarily ease of
> maintenance or
> is there perceived value to the end user? This change will
> significantly
> increase my own server maintenance and I don't even maintain that many
> servers. I love the fact that exim has always been self contained if
> desired.
Its definitely an ease of maintenance win - we don't have to track PCRE
releases (there has been another one since 4.69 came out).
I would argue its also a win for the end user/admin as they then know
that they have to maintain PCRE on a box, and if there is an issue with
that package they just need to update PCRE rather than potentially exim,
php, java...
Additionally the vast majority of exim installations I believe already
patch out the embedded PCRE and use a system one (for example this is
done on all the linux distros I have checked).
This is basically the same argument we saw 10ish years ago relating to
moving to using GIF or DB libraries rather than compiling the code into
your package.
> If there's already been a discussion of this let me know and I'll
> revie
> but I don't remember seeing it.
I have discussed this with a few people, but it was off-list. I did put
it in the 4.69 release information.
> My gut feeling is that this is related to some security fixes that
> forced
> pushing out the last release before it really had anything good in
> it and
> before the release process was streamlined, but it kind of feels
> like a
> web form that doesn't allow dashes in a credit card number - saved the
> developer 5 minutes but collectively cost the end users hours/days/
> years
> depending on how popular it is.
How many systems actually don't have PCRE available as a system library
- for heavens sake its even in Solaris (SUNWpcre package) - and they
have a 1980s runtime.
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ]
[. - Comments in this message are my own and not ITO opinion/policy - ]
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##