On Thu, Jan 24, 2019 at 03:14:43PM +0000, Matthew Vernon wrote: > Hi, > > Thanks for the bug report. The change you complain of was inherited from > Marc Haber's packaging of pcre3, as referred to in a related upstream issue: > https://bugs.exim.org/show_bug.cgi?id=1830 > > Is your objection that Marc's change is incorrect, that it's misapplied in > pcre2, or something else?
How is it inherited? It's completely different. In pcre3, the .h is patched to rename the functions and then provide compatibility macros using the standard names: https://sources.debian.org/src/pcre3/2:8.39-11/debian/patches/pcreposix.patch/ In pcre2, the names are overriden in debian/rules, and any application wishing to make use of it has to add the same definitions: export DEB_CFLAGS_MAINT_APPEND = -Dregcomp=PCRE2regcomp -Dregexec=PCRE2regexec -Dregerror=PCRE2regerror -Dregfree=PCRE2regfree Which also, quite frankly, are ugly symbol names - they should have been pcre2posix_regcomp and so on to follow pcre3. But well, can't fix that without an ABI break (or compat symbols with those names). Adopting the patch from pcre3 (using PCRE2 instead of pcreposix_ as the prefix) instead of the ad-hoc patch in debian/rules solves this bug and makes it possible for other packages to use libpcre2-posix without having to append custom cflags. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
