SCIENTIFIC-LINUX-DEVEL Archives

May 2010

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Valery Mitsyn <[log in to unmask]>
Reply To:
Valery Mitsyn <[log in to unmask]>
Date:
Sun, 9 May 2010 21:08:33 +0400
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (170 lines)
On Sun, 9 May 2010, Valery Mitsyn wrote:

> Hi,
>
> probably this is not very useful for everybody, but
> it works in this way.
> 1) install yum-metadata-parser from the CentOS:
> rpm -Uvh \
> http://ftp.chg.ru/pub/Linux/CentOS/4.8/os/i386/CentOS/RPMS/yum-metadata-parser-1.0-8.el4.centos.i386.rpm
> 2) move away two files:
> mv /usr/lib/python2.3/site-packages/yum/sqlitecache.py \
> /usr/lib/python2.3/site-packages/yum/sqlitecache.py_
> mv /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc \
> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc_

2a) copy 3 files:
/bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.py \
/usr/lib/python2.3/site-packages/yum/sqlitecache.py
/bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyc \
/usr/lib/python2.3/site-packages/yum/sqlitecache.pyc
/bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyo \
/usr/lib/python2.3/site-packages/yum/sqlitecache.pyo

> 3) now yum should works with repos:
> http://mirrors.dotsrc.org/jpackage/5.0/generic/free/
> http://mirrors.dotsrc.org/jpackage/5.0/generic/non-free/
> yum clean all
> yum -y --tsflags=test update
>
> On Fri, 7 May 2010, Valery Mitsyn wrote:
>
>> 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

ATOM RSS1 RSS2