------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1504
Simon McVittie <smcv@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |smcv@???
--- Comment #8 from Simon McVittie <smcv@???> 2014-07-21 19:30:16 ---
> If the intention of the GLib function is always to provide all possible
> matches, then I would always recommend using PCRE_NO_AUTO_POSSESS.
Thanks, I've passed that on to the GLib bug. I think that confirms that the
patches I suggested there are appropriate.
> I am at present in the middle of developing an entirely new API for PCRE
> (called PCRE2, and discussed on the list some months ago). Once this is
> done (most of the code is done and I'm working on converting the tests),
> there will be a complete revision of the documentation, and I will try
> to improve the DFA documentation to make it all clearer.
Great. If it is not intended to be API-compatible ("most" users will need
source-code changes), may I request that the result has a different basename,
.pc filename, header prefix/directory etc., perhaps pcre2, resulting in
starting from libpcre2.so.0 on Linux? This sounds like something that
distributions would need to handle as an incompatible transition like Gtk2 ->
Gtk3, and those are easiest if the versions are parallel-installable
<
http://ometer.com/parallel.html>.
> The changes were intentional (and I'm sure I bumped something, but
> perhaps not enough) but we obviously didn't recognize the extent of the
> incompatibility.
I know very little about the internals of PCRE, but I do know about libraries
in general :-)
For your information, the two important things for typical Linux distributions
(Debian, Red Hat etc.) are:
- basename of library (-lpcre vs. -lpcre2, pkg-config .pc filename,
some sort of subdirectory or prefix for header files): this is the
"API version" which goes up if "most" library users are expected to need
source-code changes
- SONAME version of library (libtool "CURRENT" minus "AGE", the 1 in
libpcre.so.1): this is the "ABI version", which goes up if library users
are expected to need a recompile to work correctly, but few or no
source-code changes.
I'd say "talk to the Debian maintainer of pcre3" (that's Mark Baker) but he
doesn't seem to be very active right now, which is why I'm helping to fix
release-critical bugs. I expect the debian-devel mailing list wouldn't mind
offering advice if you're thinking about doing an API or ABI transition,
though.
Debian currently patches our version of PCRE to be libpcre.so.3 instead of
libpcre.so.1 for historical reasons
<
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725> so if you ever bump
up the ABI version, it would make life easier if you avoided libpcre.so.2,
libpcre.so.3 and skipped straight to a higher number :-)
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
