Hi,
Sorry, but we are concentrating on SL 5.5 right now.
The one thing I did find before being distracted was that CentOS did 
several things into their yum that isn't in the standard yum.  But you 
didn't give the source rpm for them, and I never got enough time to find 
CentOS's source rpm.  so I'm not sure exactly what they did.
Their changenotes say something along the lines
  "put in the usual change"

Troy

Cristina Aiftimiei wrote:
> Hi,
> 
> is there any news?
> Sorry to disturb - but we are relly interested in having a solution.
> 
> Thank you,
> Cristina
> 
> 
> Troy Dawson wrote:
>> Peter Slížik wrote:
>>> Hi,
>>>
>>> I believe this list is the right place to report the following yum
>>> bug, which keeps causing wrinkles to the EGEE community. Apologies for
>>> the length, my intention is to provide as many details as possible.
>>>
>>> The problems started approx. on April 6, when people from the jpackage
>>> project changed the digest of their repo's digital signature from SHA
>>> to SHA1. (I think they just updated their createrepo package, because
>>> the "repomd.xml" files on my machines contained the text
>>> "<database_version>9</database_version>" before and
>>> "<database_version>10</database_version>" after the problem was first
>>> reported.) Following the change, SL4-based installations refused to
>>> cooperate, yielding the "[Errno 256] No more mirrors to try" error
>>> message upon "yum update". (SL5-based machines worked fine.) The issue
>>> was discussed on the LCG-ROLLOUT list and the discussion later moved
>>> to jpackage-discuss. People from the jpackage project then decided to
>>> return to the old SHA digest.
>>>
>>> After going back to SHA, a strange thing happened. For users who did
>>> not empty their metadata cache inbetween, the "yum update" command
>>> worked fine. But if they happened to either had run "yum clean all"
>>> (as was suggested by somebody on the list) or if they started with a
>>> fresh SL installation, "yum update" failed with the following error:
>>>
>>>   File "__init__.py", line 260, in doSackSetup
>>>   File "repos.py", line 287, in populateSack
>>>   File "sqlitecache.py", line 96, in getPrimary
>>>   File "sqlitecache.py", line 89, in _getbase
>>>   File "sqlitecache.py", line 359, in updateSqliteCache
>>>   File "sqlitecache.py", line 251, in addPrimary
>>>   File "sqlitecache.py", line 197, in insertHash
>>>   File "sqlitecache.py", line 449, in values
>>>   File "sqlitecache.py", line 441, in __getitem__
>>>   File "mdparser.py", line 73, in __getitem__
>>> KeyError: 'sourcerpm'
>>>
>>>
>>> Steps to reproduce the problem:
>>>
>>> 1. Create two virtual machines. Install CentOS 4.8 and Scientific
>>> Linux 4.8 on them.
>>> 2. Run "yum update" on both. This is just to reduce the number of
>>> yum's outputs later.
>>> 3. Download the jpackage repository to /etc/yum.repos.d/
>>>     
>>> http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/3.1/jpackage.repo 
>>>
>>> 4. Run "yum update". This will succeed on CentOS 4.8 and fail on SL 4.8.
>>>
>>>
>>> After some investigation, I found a strange thing. Though "yum
>>> --version" reports "2.4.3" on both platforms, the actual
>>> implementations differ. Apart from the obvious configuration stuff
>>> (e.g. cron.d files, /etc/init.d scripts) they differ also in the way
>>> they handle cache. The following files are actually different:
>>>
>>>     config.py
>>>     depsolve.py
>>>     repos.py
>>>
>>> The CentOS implementation has also one additional file:
>>>
>>>     storagefactory.py.
>>>
>>> Unfortunatelly, I wasn't able to find the actual cause of the error.
>>>
>>>
>>> If you need to compare the files without installing the whole
>>> distributions, please feel free to download the following archives:
>>>
>>>     http://petersbytes.net/tmp/yum-2.4.3-4.el4.centos.noarch.rpm
>>>     http://petersbytes.net/tmp/yum-2.4.3-10.SL.noarch.rpm
>>>
>>> There are two possible conclusions: either the CentOS developers
>>> messed with the implementation without increasing the version number,
>>> or the Upstream Vendor issued a new release without increasing the
>>> version number and Scientific Linux did not catch with them. Either
>>> way, I think the problem needs to be patched in SL, because I don't
>>> think that jpackage people will fix the problem on their part -
>>> they're testing their stuff on CentOS and everything works fine for
>>> them.
>>>
>>> Best regards,
>>>
>>> Peter Slizik
>> Hi Peter,
>> Thanks for the information and the detailed analysis.
>> I'm looking into this.
>> I am pretty sure that we did not take any files out of yum 2.4.3.  We 
>> changed a file or two, but never took any out.  I'll look through 
>> CentOS's yum rpm and see what the difference is and let you know if a 
>> little bit.
>> Thanks
>> Troy
> 
> 


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