FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 12-31-2007, 03:53 AM
"Devraj Mukherjee"
 
Default Yum breaks after updating to CentOS 4.6

Hi everyone,

Yum on one my CentOS systems has decided to stop functioning after an
upgrade to CentOS 4.6. It's complaining about errors with
Python-SQLite packages?

Any ideas anyone? Here is what happens.

[root@monk var]# yum search zaptel
Setting up repositories
Reading repository metadata in from local files
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in ?
yummain.main(sys.argv[1:])
File "/usr/share/yum-cli/yummain.py", line 102, in main
result, resultmsgs = do()
File "/usr/share/yum-cli/cli.py", line 545, in doCommands
return self.search()
File "/usr/share/yum-cli/cli.py", line 1129, in search
for (po, matched_value) in matching:
File "__init__.py", line 1157, in searchGenerator
File "sqlitesack.py", line 52, in returnSimple
File "sqlitesack.py", line 273, in getPackageDetails
File "sqlitesack.py", line 403, in db2class
File "/var/tmp/python-sqlite-root//usr/lib/python2.3/site-packages/sqlite/main.py",
line 97, in __getattr__
AttributeError: LOCATION_BASE


--
"I never look back darling, it distracts from the now", Edna Mode (The
Incredibles)
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2007, 04:49 AM
"Akemi Yagi"
 
Default Yum breaks after updating to CentOS 4.6

On Dec 30, 2007 8:53 PM, Devraj Mukherjee <devraj@gmail.com> wrote:
> Hi everyone,
>
> Yum on one my CentOS systems has decided to stop functioning after an
> upgrade to CentOS 4.6. It's complaining about errors with
> Python-SQLite packages?
>
> Any ideas anyone? Here is what happens.
>
> [root@monk var]# yum search zaptel
> Setting up repositories
> Reading repository metadata in from local files
> Traceback (most recent call last):
> File "/usr/bin/yum", line 29, in ?
> yummain.main(sys.argv[1:])
> File "/usr/share/yum-cli/yummain.py", line 102, in main
> result, resultmsgs = do()
> File "/usr/share/yum-cli/cli.py", line 545, in doCommands
> return self.search()
> File "/usr/share/yum-cli/cli.py", line 1129, in search
> for (po, matched_value) in matching:
> File "__init__.py", line 1157, in searchGenerator
> File "sqlitesack.py", line 52, in returnSimple
> File "sqlitesack.py", line 273, in getPackageDetails
> File "sqlitesack.py", line 403, in db2class
> File "/var/tmp/python-sqlite-root//usr/lib/python2.3/site-packages/sqlite/main.py",
> line 97, in __getattr__
> AttributeError: LOCATION_BASE

Take a look at this thread (an answer from Johnny Hughes for the same question):

http://lists.centos.org/pipermail/centos/2007-December/091669.html

Akemi
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2007, 05:41 AM
Johnny Hughes
 
Default Yum breaks after updating to CentOS 4.6

Akemi Yagi wrote:
> On Dec 30, 2007 8:53 PM, Devraj Mukherjee <devraj@gmail.com> wrote:
>> Hi everyone,
>>
>> Yum on one my CentOS systems has decided to stop functioning after an
>> upgrade to CentOS 4.6. It's complaining about errors with
>> Python-SQLite packages?
>>
>> Any ideas anyone? Here is what happens.
>>
>> [root@monk var]# yum search zaptel
>> Setting up repositories
>> Reading repository metadata in from local files
>> Traceback (most recent call last):
>> File "/usr/bin/yum", line 29, in ?
>> yummain.main(sys.argv[1:])
>> File "/usr/share/yum-cli/yummain.py", line 102, in main
>> result, resultmsgs = do()
>> File "/usr/share/yum-cli/cli.py", line 545, in doCommands
>> return self.search()
>> File "/usr/share/yum-cli/cli.py", line 1129, in search
>> for (po, matched_value) in matching:
>> File "__init__.py", line 1157, in searchGenerator
>> File "sqlitesack.py", line 52, in returnSimple
>> File "sqlitesack.py", line 273, in getPackageDetails
>> File "sqlitesack.py", line 403, in db2class
>> File "/var/tmp/python-sqlite-root//usr/lib/python2.3/site-packages/sqlite/main.py",
>> line 97, in __getattr__
>> AttributeError: LOCATION_BASE
>
> Take a look at this thread (an answer from Johnny Hughes for the same question):
>
> http://lists.centos.org/pipermail/centos/2007-December/091669.html
>
> Akemi

OK .. it seems that ATRPMS (a 3rd party repo) has a version of yum in
the EL4 repo that breaks centos 4:

http://atrpms.net/dist/el4/yum/

If you use *_ANY_* 3rd party repo *_IMHO_* you *_MUST_* use the
yum-priorities (or yum-plugin-priorities for CentOS-4) plugin to prevent
things like this from happening:

http://wiki.centos.org/PackageManagement/Yum/Priorities

Thanks,
Johnny Hughes




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2007, 08:53 AM
Axel Thimm
 
Default Yum breaks after updating to CentOS 4.6

On Mon, Dec 31, 2007 at 12:41:52AM -0600, Johnny Hughes wrote:
> Akemi Yagi wrote:
> > On Dec 30, 2007 8:53 PM, Devraj Mukherjee <devraj@gmail.com> wrote:
> >> Hi everyone,
> >>
> >> Yum on one my CentOS systems has decided to stop functioning after an
> >> upgrade to CentOS 4.6. It's complaining about errors with
> >> Python-SQLite packages?
> >>
> >> Any ideas anyone? Here is what happens.
> >>
> >> [root@monk var]# yum search zaptel
> >> Setting up repositories
> >> Reading repository metadata in from local files
> >> Traceback (most recent call last):
> >> File "/usr/bin/yum", line 29, in ?
> >> yummain.main(sys.argv[1:])
> >> File "/usr/share/yum-cli/yummain.py", line 102, in main
> >> result, resultmsgs = do()
> >> File "/usr/share/yum-cli/cli.py", line 545, in doCommands
> >> return self.search()
> >> File "/usr/share/yum-cli/cli.py", line 1129, in search
> >> for (po, matched_value) in matching:
> >> File "__init__.py", line 1157, in searchGenerator
> >> File "sqlitesack.py", line 52, in returnSimple
> >> File "sqlitesack.py", line 273, in getPackageDetails
> >> File "sqlitesack.py", line 403, in db2class
> >> File "/var/tmp/python-sqlite-root//usr/lib/python2.3/site-packages/sqlite/main.py",
> >> line 97, in __getattr__
> >> AttributeError: LOCATION_BASE
> >
> > Take a look at this thread (an answer from Johnny Hughes for the same question):
> >
> > http://lists.centos.org/pipermail/centos/2007-December/091669.html
> >
> > Akemi
>
> OK .. it seems that ATRPMS (a 3rd party repo) has a version of yum in
> the EL4 repo that breaks centos 4:
>
> http://atrpms.net/dist/el4/yum/

Hm, why does that break CentOS4? It works fine here on RHEL4. We
should find the cause and fix it.

> If you use *_ANY_* 3rd party repo *_IMHO_* you *_MUST_* use the
> yum-priorities (or yum-plugin-priorities for CentOS-4) plugin to prevent
> things like this from happening:
>
> http://wiki.centos.org/PackageManagement/Yum/Priorities

Well, allow me to present a different view: As a third party repo
maintainer I can't support all possible
priority/weighing/protectbase/etc. filtering and reordering mechanisms
out there. These selective/partial enablement or repos have caused far
more bugs that they solved (like not downloading the proper part of
the dependencies needed for some functionality) - and all bugs are of
personal nature to the reporter as they depend on how they configured
their filtering.

So the recommendation from ATrpms is to *not* use such mechanisms. And
the successor of ATrpms is working on mechanisms to allow this to
happen for a set of filtering profiles on a server side (e.g. offer a
full and a non-replacing subrepo), so that the repo maintainers can
actually know what the two different user profiles are using and even
replicate this on their systems.

Short story: Compatibility between repos must be coordinated by
humans, not yum plugins, and in this case I'll move the yum package
away into the "bleeding" area until we figure out what is causing the
CentOS4 extra packages vs ATrpms incompatibility (and it could be that
priorities are actually causing this bug, as this yum needs some more
dependencies that the old one - if it had been a general issue there
would be far more CentOS/SL/RHEL4 users crying out).
--
Axel.Thimm at ATrpms.net
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2007, 11:44 AM
Johnny Hughes
 
Default Yum breaks after updating to CentOS 4.6

Axel Thimm wrote:
> On Mon, Dec 31, 2007 at 12:41:52AM -0600, Johnny Hughes wrote:
>> Akemi Yagi wrote:
>>> On Dec 30, 2007 8:53 PM, Devraj Mukherjee <devraj@gmail.com> wrote:
>>>> Hi everyone,
>>>>
>>>> Yum on one my CentOS systems has decided to stop functioning after an
>>>> upgrade to CentOS 4.6. It's complaining about errors with
>>>> Python-SQLite packages?
>>>>
>>>> Any ideas anyone? Here is what happens.
>>>>
>>>> [root@monk var]# yum search zaptel
>>>> Setting up repositories
>>>> Reading repository metadata in from local files
>>>> Traceback (most recent call last):
>>>> File "/usr/bin/yum", line 29, in ?
>>>> yummain.main(sys.argv[1:])
>>>> File "/usr/share/yum-cli/yummain.py", line 102, in main
>>>> result, resultmsgs = do()
>>>> File "/usr/share/yum-cli/cli.py", line 545, in doCommands
>>>> return self.search()
>>>> File "/usr/share/yum-cli/cli.py", line 1129, in search
>>>> for (po, matched_value) in matching:
>>>> File "__init__.py", line 1157, in searchGenerator
>>>> File "sqlitesack.py", line 52, in returnSimple
>>>> File "sqlitesack.py", line 273, in getPackageDetails
>>>> File "sqlitesack.py", line 403, in db2class
>>>> File "/var/tmp/python-sqlite-root//usr/lib/python2.3/site-packages/sqlite/main.py",
>>>> line 97, in __getattr__
>>>> AttributeError: LOCATION_BASE
>>> Take a look at this thread (an answer from Johnny Hughes for the same question):
>>>
>>> http://lists.centos.org/pipermail/centos/2007-December/091669.html
>>>
>>> Akemi
>> OK .. it seems that ATRPMS (a 3rd party repo) has a version of yum in
>> the EL4 repo that breaks centos 4:
>>
>> http://atrpms.net/dist/el4/yum/
>
> Hm, why does that break CentOS4? It works fine here on RHEL4. We
> should find the cause and fix it.

Maybe the breakage is caused by something like yum-metadata-parser or
some of the yum plugins that are written for the older version of yum.

>
>> If you use *_ANY_* 3rd party repo *_IMHO_* you *_MUST_* use the
>> yum-priorities (or yum-plugin-priorities for CentOS-4) plugin to prevent
>> things like this from happening:
>>
>> http://wiki.centos.org/PackageManagement/Yum/Priorities
>
> Well, allow me to present a different view: As a third party repo
> maintainer I can't support all possible
> priority/weighing/protectbase/etc. filtering and reordering mechanisms
> out there. These selective/partial enablement or repos have caused far
> more bugs that they solved (like not downloading the proper part of
> the dependencies needed for some functionality) - and all bugs are of
> personal nature to the reporter as they depend on how they configured
> their filtering.

Well ... that is true. However the user should only need to worry about
that if there is a conflict.

I recommend the same plugin if using the CentOSPlus repo too (and I
maintain that so this was/is not directed at ATRPMS singularly), as I
just do not want to replace base packages unless is absolutely necessary.

The whole purpose of CentOS is a stable base, and packages that replace
base packages should be individually thought about only replaced if
absolutely necessary.

Just like you can not support every filtering mechanism when used in
conjunction with every third party repo, CentOS can not support problems
caused by replacing base packages ... so replacement should be a last
resort kind of thing.

This is just my opinion ... and again not directed at any particular 3rd
party repo.

>
> So the recommendation from ATrpms is to *not* use such mechanisms. And
> the successor of ATrpms is working on mechanisms to allow this to
> happen for a set of filtering profiles on a server side (e.g. offer a
> full and a non-replacing subrepo), so that the repo maintainers can
> actually know what the two different user profiles are using and even
> replicate this on their systems.
>
> Short story: Compatibility between repos must be coordinated by
> humans, not yum plugins, and in this case I'll move the yum package
> away into the "bleeding" area until we figure out what is causing the
> CentOS4 extra packages vs ATrpms incompatibility (and it could be that
> priorities are actually causing this bug, as this yum needs some more
> dependencies that the old one - if it had been a general issue there
> would be far more CentOS/SL/RHEL4 users crying out).
>

Everyone is entitled to their own opinion ... mine is that the yum from
CentOS is a critical package and should not be replaced with out a very,
very good reason. Yours is different. Neither is right or wrong ...
they are just different approaches.

Thanks,
Johnny Hughes

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2007, 12:03 PM
Axel Thimm
 
Default Yum breaks after updating to CentOS 4.6

On Mon, Dec 31, 2007 at 06:44:08AM -0600, Johnny Hughes wrote:
> Everyone is entitled to their own opinion ... mine is that the yum from
> CentOS is a critical package and should not be replaced with out a very,
> very good reason. Yours is different. Neither is right or wrong ...
> they are just different approaches.

Sure, and ATrpms' policy wrt to RHEL is to move replacing packages
into the testing repo until a better solution is found. Only that yum
is not part of RHEL4 end even worse, different clones of RHEL use
different yum versions and different sets of (sometimes home-made)
plugins. E.g. when talking about "replacing base packages" in RHEL &
clone worlds it becomes quite obfuscated.

The yum in ATrpms is there for two reasons:

o making sure RHEL users also have a yum, but more important
o several yum bugs that are triggered by some ATrpms packages have
been fixed in later yum version w/o a backport. ATM some plugins and
repo policies had unconvered yet another pile of yum bugs that were
fixed with 3.2.8 and affected many ATrpms packages (the infamous:
"Your installed kernel is not installed" installonly bug).

So wrt to yum and a couple similar infratsructure packages it would be
nice to have a canonical clone (e.g. from my POV a merged CentOS/SL
universe, something I've been advocating) to define as base and then
either invest in backporting bugfixes (which is difficult given that
yum is at a fast pace and the authors almost never do backports), or
update yum more often to remove these bugs (which involves testing yum
on CentOS3-5).

But this gets off the centos-user list charter a bit, I do hope that
working together on the merged 3rd party repo will have side-effects
like bringing CentOS/SL even closer and at the end not even have to
worry about 3rd party repos. Maybe we should move part of this
discussions to other lists. As a short term fix we could discuss on
centos/sl-devel whether a new common yum infrastructure could be
shared by centos/sl and atrpms (and maybe other 3rd party repos, I
think maybe Dag or Dries may have yum shipping, too) removing its own?
--
Axel.Thimm at ATrpms.net
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2007, 12:37 PM
Johnny Hughes
 
Default Yum breaks after updating to CentOS 4.6

Axel Thimm wrote:
> On Mon, Dec 31, 2007 at 06:44:08AM -0600, Johnny Hughes wrote:
>> Everyone is entitled to their own opinion ... mine is that the yum from
>> CentOS is a critical package and should not be replaced with out a very,
>> very good reason. Yours is different. Neither is right or wrong ...
>> they are just different approaches.
>
> Sure, and ATrpms' policy wrt to RHEL is to move replacing packages
> into the testing repo until a better solution is found. Only that yum
> is not part of RHEL4 end even worse, different clones of RHEL use
> different yum versions and different sets of (sometimes home-made)
> plugins. E.g. when talking about "replacing base packages" in RHEL &
> clone worlds it becomes quite obfuscated.
>
> The yum in ATrpms is there for two reasons:
>
> o making sure RHEL users also have a yum, but more important
> o several yum bugs that are triggered by some ATrpms packages have
> been fixed in later yum version w/o a backport. ATM some plugins and
> repo policies had unconvered yet another pile of yum bugs that were
> fixed with 3.2.8 and affected many ATrpms packages (the infamous:
> "Your installed kernel is not installed" installonly bug).

We are working on a yum-3.2.8 version for CentOS-5 as well, as there is
a major bug in the 3.0.x branch that causes problems with file paths
used with file dependency calculations. However, just like we don't
roll newer KDE changes back into CentOS-4 and CentOS-3, we will probably
not upgrade the yum in centos-4 or centos-3 to yum-3.2.8.

We have added a new version of yum (the same version in centos-4) into
the CentOS-3 CentOSPlus repo. The problem is that the new versions of
yum require new versions of python ... and python is not something that
we recommend updating .. EVER

That means that either we have to change the newer yum versions to work
with the older python or create newer a python to use in conjunction
with the older python on older versions of CentOS.

We are backporting things to older centos versions ... the c3 plus
version of yum is one example, another is the new centos-metadata-parser
rolled back into centos-4 from centos-5. However we do this with much
testing and it takes much time to modify these to work with the older
pythons.

But we have thousands of CentOS-3 users who are perfectly happy with the
old yum 2.0.8 and it works for them, so we did not put the yum upgrade
for CentOS-3 into base, but into centosplus.

We do this since one of the main purposes of Enterprise software, once
it is installed, is to not break (or even change) anything it already
does ... so there is a GOAL to not upgrade anything unless it is
absolutely required once released.

>
> So wrt to yum and a couple similar infratsructure packages it would be
> nice to have a canonical clone (e.g. from my POV a merged CentOS/SL
> universe, something I've been advocating) to define as base and then
> either invest in backporting bugfixes (which is difficult given that
> yum is at a fast pace and the authors almost never do backports), or
> update yum more often to remove these bugs (which involves testing yum
> on CentOS3-5).

We have to mix that with not changing any released package ... and if it
changes, not changing the ABI/APIs but only the bugs. We can't break
update scripts written to use our yum by people who have 10,000 clients
because we want a shiny new feature ... or maybe even if we want to fix
a bug.

>
> But this gets off the centos-user list charter a bit, I do hope that
> working together on the merged 3rd party repo will have side-effects
> like bringing CentOS/SL even closer and at the end not even have to
> worry about 3rd party repos. Maybe we should move part of this
> discussions to other lists. As a short term fix we could discuss on
> centos/sl-devel whether a new common yum infrastructure could be
> shared by centos/sl and atrpms (and maybe other 3rd party repos, I
> think maybe Dag or Dries may have yum shipping, too) removing its own?

Yes, but their's (dag/dries) is older than the one in CentOS. I
recommend using the priorities plugin against rpmforge and
kbs-CentOS-Extras too.

I am an equal opportunity filterer

Thanks,
Johnny Hughes

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2007, 01:35 PM
Axel Thimm
 
Default Yum breaks after updating to CentOS 4.6

On Mon, Dec 31, 2007 at 07:37:34AM -0600, Johnny Hughes wrote:
> We are working on a yum-3.2.8 version for CentOS-5 as well, as there is
> a major bug in the 3.0.x branch that causes problems with file paths
> used with file dependency calculations. However, just like we don't
> roll newer KDE changes back into CentOS-4 and CentOS-3, we will probably
> not upgrade the yum in centos-4 or centos-3 to yum-3.2.8.

I wouldn't compare yum to kde/gnome/glibc. The same reasoning behind
upgrading from 3.0.x to 3.2.x can be used for 2.0.x. In fact the diffs
between 3.0.x to 3.2 are IMHO larger than 2 to 3.

And RHEL4/3 didn't ship any yum at all, so you have larger degrees of
freedom in CentOS than in CentOS5, where there is a yum 3.0.x shipped
by the vendor and according to "clone-the-bugs-as-well" one has to
keep the pure CentOS5 parts to 3.0.1. :/

> The problem is that the new versions of yum require new versions of
> python ... and python is not something that we recommend updating
> .. EVER

Of course.

> That means that either we have to change the newer yum versions to work
> with the older python or create newer a python to use in conjunction
> with the older python on older versions of CentOS.

Yes, for example a while back (actually 2 years ago) I had to create
python24 to allow smart support in RHEL3 and RHEL4 as well as FC5 at
that time (or maybe FC4, can't remember exactly). Later smart relaxed
the python requirements and I could mostly use the system python (but
an interesting lesson was that people were using python24 for several
other things as well). Same is true for yum/apt and their
dependencies, be that python or libxml etc. One can always find a way
to sideinstall these dependencies w/o breaking the vendor's packages.

In general for infrastructural bits like yum/apt/smart I would follow
a different policy than never-update-always-backport, especially when
they are not part of the cloned master. Many yum security issues are
not even raised from old releases as they valnish too quickly, so at
the end CentOS has a copy of yum that upstream doesn't support and
needs to code review itself and also try to backport important
security and bug fixes sometimes into code that looks like from a
different project.

> But we have thousands of CentOS-3 users who are perfectly happy with the
> old yum 2.0.8 and it works for them, so we did not put the yum upgrade
> for CentOS-3 into base, but into centosplus.

Well, I dare to assert that for every thousand users happy with yum
2.0.x you will find 2000 users that are unhappy with it
--
Axel.Thimm at ATrpms.net
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 03:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org