Hi Michael,
Those were the good old days (which still occasionally happen) of 
"poorly named rpms".  Those are rpm's that use the %dist variable, and 
that we have to guess what it should be.  Easy to do by hand, (of course 
%dist is el5_1 and not el5) but harder to code into a script.  That was 
our early days of figuring out the scripts and fixing everything.

You really  want pcre-6.6-2.el5_1.7.src.rpm and not 
pcre-6.6-2.el5.7.src.rpm.

Just out of curiousity, if you want to build it for yourself, why are 
you getting the src.rpm from us and not RedHat?
http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/

Troy

Michael Tiernan wrote:
> I'm a smidge confused by something. I am looking at the timestamps on a 
> couple of the SRPMS and something seems to be amiss.
> 
> In ftp://ftp.scientificlinux.org/linux/scientific/5x/SRPMS/vendor are 
> these files:
> 
>     -rw-r--r-- 1 root root 568054 Nov 15  2007 pcre-6.6-2.el5.1.0.1.src.rpm
>     -rw-r--r-- 1 root root 570887 Mar 27  2009 pcre-6.6-2.el5_1.7.src.rpm
>     -rw-r--r-- 1 root root 567559 Nov 13  2007 pcre-6.6-2.el5.1.src.rpm
>     -rw-r--r-- 1 root root 570836 Nov 29  2007 pcre-6.6-2.el5.7.src.rpm
>     -rw-r--r-- 1 root root 568035 Nov 15  2007 pcre-6.6-2.sl5.1.src.rpm
> 
> it seems to be that the file el5_1 is newer than el5.7 but I wanted to 
> see if anyone had any opinions on it since the RPMS reflect a different 
> story.
> 
>     Release     : 2.el5.1.0.1                   Build Date: Thu 15 Nov
>     2007 02:57:05 PM GMT
>     Release     : 2.el5_1.7                     Build Date: Mon 26 Nov
>     2007 11:49:29 AM GMT
>     Release     : 2.el5.1                       Build Date: Tue 13 Nov
>     2007 05:20:59 PM GMT
>     Release     : 2.el5.7                       Build Date: Thu 29 Nov
>     2007 07:13:57 PM GMT
>     Release     : 2.sl5.1                       Build Date: Thu 15 Nov
>     2007 02:45:30 PM GMT
> 
> Which seems to indicate that el5.7 is the newest package.
> 
> Does anyone have any opinions on this? I'm going to try to rebuild this 
> one package for myself but I'd like to do it with the right sources.
> 
> P.S. For those interested, here's what I'm trying to address:
> 
>     /https://bugzilla.redhat.com/show_bug.cgi?id=457064
>     http://bugs.centos.org/view.php?id=3252
>     http://chrisjean.com/2009/01/31/unicode-support-on-centos-52-with-php-and-pcre/
> 
>     Long story short, it's trivial to fix, but RedHat prefers to leave
>     it open in its RHEL product. CentOS folks get it copied from RHEL
>     (and also don't fix it), and RackTables is not the first application
>     to be impacted by this bug.
> 
>     A way to work around that would be to revert a part of the recent
>     switch to uniform PCRE, namely, to employ mb_ereg() for character
>     class matching again. For me this looks to be only a temporary
>     measure (given, that ereg() is already deprecated) and adds
>     undesired maintenance overhead.
> 
>     This is where you can help. I am looking for a RHEL user with a
>     support contract, which they could use to push RedHat's bug 457064
>     to be properly fixed (and working RPM put into updates). Technically
>     it is a very simple work, but if we could make it done, that would
>     help a lot./
> 
> -- 
>   << MCT >>   Michael C Tiernan.   xmpp:[log in to unmask]
>   MIT - Laboratory for Nuclear Science - http://www.lns.mit.edu
>   High Perf Research Computing Facility at The Bates Linear Accelerator
>   "Bit-smashing your bits better than anyone can!"
> 


-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LSCS/CSI/USS Group
__________________________________________________