On Fri, 7 May 2010, Troy Dawson wrote: > 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. Could it be in the yum-metadata-parser rpm which is in require list of yum in centos? One can test this case by installing yum-metadata-parser from centos repo to SL4X. > 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 >> >> > > > -- Best regards, Valery Mitsyn