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