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

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

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 :D

Thanks, Johnny Hughes