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