PCRE 8.30 will break API

[Sérgio Basto]

On Thu, 2012-02-09 at 16:52 +0000, Petr Pisar wrote: 
> It's long time since PCRE (Perl-Compatible Regular Expression) library
> has changed API or ABI. Version 8.30 is different. Besides UTF-16
> support, the incompatible changes are described by upstream with these
> words:
> 
> . The pcre_info() function, which has been obsolete for over 10 years,
>   has been removed.
> 
> . When a compiled pattern was saved to a file and later reloaded on
>   a host with different endianness, PCRE used automatically to swap the
>   bytes in some of the data fields. With the advent of the 16-bit
>   library, where more of this swapping is needed, it is no longer done
>   automatically. Instead, the bad endianness is detected and a specific
>   error is given. The user can then call a new function called
>   pcre_pattern_to_host_byte_order() (or an equivalent 16-bit function)
>   to do the swap.
> 
> . In UTF-8 mode, the values 0xd800 to 0xdfff are not legal Unicode code
>   points and are now faulted. (They are the so-called "surrogates" that
>   are reserved for coding high values in UTF-16.)
> 
> Result is pcre library has changed SONAME from libpcre.so.0 to
> libpcre.so.1. Other librararies (pcrecpp, pcreposix) delivered with this
> package remain compatible.
> 
> Because pcre library is part of minimal build root I choosed following
> strategy to avoid breaking Koji:
> 
> (1) pcre-8.30-1 will include both new libpcre.so.1 and old libpcre.so.0.
>     (This is done by copying old files from build root while building
>     this new package).
> 
> (2) Reverse dependencies will be rebuilt against this new library.
>     x86_64 repository returns 109 packages:
> 
>     adanaxisgpl
>     blender
>     bti
>     cclive
>     ccze
>     cduce
>     cegui
>     cegui06
>     cfengine
>     classads
>     coccinelle
>     collada-dom
>     condor
>     dansguardian
>     EMBOSS
>     eterm
>     ettercap
>     exim
>     fsniper
>     gambas2
>     gambas3
>     ganglia
>     ghc-hakyll
>     ghc-pcre-light
>     ghc-regex-pcre
>     git
>     gnaughty
>     gnome-mud
>     gnote
>     gource
>     grep
>     gsmartcontrol
>     gxneur
>     haproxy
>     highlighting-kate
>     httpd
>     imapfilter
>     Io-language
>     kannel
>     kaya
>     kdelibs
>     kdelibs3
>     kismet
>     leafnode
>     ledger
>     less
>     libast
>     libguestfs
>     lighttpd
>     logstalgia
>     lua-rex
>     maildrop
>     matahari
>     mboxgrep
>     mcstrans
>     medusa
>     mod_security
>     mongodb
>     monotone
>     mysql-workbench
>     nekovm
>     nginx
>     ngrep
>     nmap
>     ocaml-ocamlnet
>     octave
>     openCOLLADA
>     openscada
>     openscap
>     opensips
>     ovaldi
>     pads
>     pandoc
>     perl-HTML-Template-Pro
>     php
>     picviz
>     pidgin-musictracker
>     poco
>     postfix
>     prelude-lml
>     privoxy
>     proftpd
>     R
>     regexxer
>     rekall
>     root
>     scilab
>     slang
>     spring-installer
>     sssd
>     suricata
>     swig
>     syncevolution
>     syslog-ng
>     tabled
>     Thunar
>     tin
>     tintin
>     tinyfugue
>     varnish
>     wmweather+
>     xastir
>     xfce4-verve-plugin
>     xgrep
>     xmlcopyeditor
>     xneur
>     znc-infobot
>     zoneminder
>     389-ds-base
> 
> (3) pcre package will be rebuilt again without the old libpcre.so.0 library.
>     The usr-move of /lib*/libpcre.so* will proceede in this or another
>     rebuild.

And sed is not affected ?

I got a problem with kmk_sed from kBuild, which change his behavior on
F-17, I don't know exactly when, if it is gcc 4.7 if it is glibc , but
just in case could you rebuild kBuild ? 

Thanks, 
-- 
Sérgio M. B.