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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
