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
__________________________________________________