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