yum reports old version with ensure=>latest

We had that a while ago, the problem is that 'list updates' does zip if the package is not installed yet.

Can you describe in more detail the problem you encountered ? (What's the yum config, what package were you trying to update, which version was installed)

Proposed patch

Patch has been tested on RHEL3 and RHEL4 w/ yum 2.0.7.

This patch is required for proper functioning w/ yum 2.0.7 (yum < 2.4 doesn't support a package name after "list available").

I don't really understand that patch - it seems that nothing is ever appended to result since I can't see how the regexp will ever match a line of output from yum. (It ends with 'db\s*$' ??)

Also, CentOS 4 ships with yum 2.4.x, so the only distro that is a problem is CentOS 3 (which has yum 2.0.8)

Again, to help me understand this better, can you give me some more details on what happened ?

Not sure on yum > 2.0.x, but on 2.0.x "list available" shows the version that is installed (ending with db for the repository) and the versions that are available (ending with the name of the repository). The line with 'db\s*$' strips out the versions that are installed locally so the only results after that are the ones from the yum repositories.

We are using yum 2.0.7 with rhel3, which doesn't ship with a version at all. I suspect that 2.0.8 will behave similarly to 2.0.7, but the size of our installed base makes upgrading prohibitive.

Without the patch, every time we ran puppet it would think the installed package is out of date and would re-install it every time.

with yum 3.

configure two repos which provide the same package, but different versions of it. in my example it is FC6 extras facter (the repo with the old version is an internal one).

there's facter 1.3.7 installed, but "yum list available facter" reports there is a new version.

may be it is a yum bug, or may be it is the correct behaviour yum saying "you have this (older) package available"). I dont know.

[root@arxiver016 ~]# rpm -qa facter
facter-1.3.7-1.fc6

[root@arxiver016 ~]# yum list available facter
Loading "installonlyn" plugin
Setting up repositories
Reading repository metadata in from local files
Available Packages
facter.i386                              1.3.6-1.el4            epel            

[root@arxiver016 ~]# yum update facter
Loading "installonlyn" plugin
Setting up Update Process
Setting up repositories
Reading repository metadata in from local files
Could not find update match for facter
No Packages marked for Update/Obsoletion

Could you run 'yum -d 0 -e 0 check-update; echo $?' on one of those machines, ideally on one that has updates pending, and on one that doesn't ?

with "yum search puppet" we have this packages available:

puppet.noarch                            0.18.4-2.el4.kb        kbs-CentOS-Extra
puppet.noarch                            0.23.0-1.el5           DLutter-repo
puppet.i386                              0.22.2-1               internal-updates
puppet.i386                              0.22.3-1               internal-updates
puppet.noarch                            0.23.0-1.el5           installed

if we put an ensure => latest declaration to puppet package in our manifests, we get this message:

Package[puppet]/ensure) ensure changed '0.23.0-1.el5' to '0.22.3-1'

but 0.23 version remains installed.
executing 'yum -d 0 -e 0 check-update; echo $?' gives us a lot of packages to update, but not puppet, and $? is 100
running this tests on:
puppet: 0.23.0-1.el5
yum: 2.4.3-1.c4
OS: RHEL 4.4
but also reproduced in several Fedora and yum versions

Can you try this with the latest incarnation of the yum provider from my tree ?

In particular, can you run the yumhelper.py script that that checkin introduces (with 'python yumhelper.py') and make sure that the results are what you'd expect ?

Potential fix for 0.24.1-1?

I don't do ruby, but Tom, a good friend of mine has kindly sent me this patch which seems to fix the problem in 0.24.1-1.

I had hoped it would be a simple fix, as "yum check-update $RPM" will return 100 if an update is available, 0 if not, but I couldn't find anywhere where yum is called directly in version 0.24.1-1. I know I'm not the brightest bulb in the chandelier, so perhaps someone more knowledgeable could have a look?

David, can you confirm that this is fixed?

This is indeed fixed with the changes to the yum provider in 0.24