rpm query for highest numbered version of a package

[Mudgen]

I'm working on a deployment image for use across a range of hardware, and one thing that's often necessary is to boot rescue, chroot, and rebuild the initial ramdisk to get the necessary drivers build into initrd/initramfs.

I have most of that worked out, but a simple thing is stumping me. I need to pick off the latest version of kernel installed to use in the mkinitrd command. "rpm -q kernel" returns them in the order I want on my test instances, but I'm concerned that it's not reliable, perhaps returns them in order installed rather than ascending version. I _might_ be able to rely on the most recent /boot/vmlinuz*, but I'd rather use an repm query.

Can any of my colleagues out there tell me how to construct an rpm query that will return the highest number kernel version installed, or all of them sorted low to high?

[Irithori]

This might be a start

rpm -q --queryformat='%{VERSION}-%{RELEASE}\n' kernel

You should be able to sort a list of versions first

rpm -q --queryformat='%{VERSION}\n'

and then decide on the release in the same way.

However, this is a clumsy way of solving this.
I will dig into the man pages/rpmdocu, there is hopefully a way to use the version/release decision methods of rpm itself.

[Mudgen]

Thanks, Irithori. I thought of variations on that, but the problem seems to be that RELEASE can look like "194.8.1.0.1.el5" or "53.1.4.el5", so I have the same problem as sorting on the whole package name. I can try to parse it out, but I don't know how many significant terms I could encounter.

VERSION is the same for both those releases, 2.6.18. I misused the term in my OP.

[Irithori]

There doesnt seem to be a way with rpm directly.
I talked about the issue with a colleague.
rpm -q returns matches in the same order as the entries are in rpmdb (berkleydb).

What you might take as a halfway certain criteria isthe %{BUILDTIME} of the package.

aka:

rpm -q --queryformat='%{BUILDTIME} %{VERSION}-%{RELEASE}\n' kernel | sort -rn | head -n 1

[Mudgen]

Thanks. Around here, I'm the colleague that people talk to about stuff like this.

BUILDTIME may be the closest I could get, and for a controlled situation like a deployment image may be good enough, since I shouldn't have to worry about some rogue kernel package with a spoofed time. I just want to embed a script in the image that will work for my brethren who use it (sorry Hazel, is "sistern" a word?).

This annoys me, because rpm knows when you're trying to install a lower-versioned rpm over an installed package, I just can't figure out how it tells.

OTOH, if we'd just semi-standardize on hardware around here, I could build a one-size-fits-all initrd and be done with it.

[Irithori]

Taking rpm 4.4.2.x as a search basis (as this is still used in redhat/centos/etc 5.X), I found the function rpmVersionCompare:
rpm: lib/psm.c Source File

Which calls rpmvercmp for version first,
and if that isn´t enough, it calls rpmvercmp again for release.
rpm: lib/rpmlib.h File Reference
-->
rpm: lib/rpmvercmp.c Source File


My C is a bit too rusty to really evaluate this alphanumerical string comparsion to what sort does.
But there doesn´t seem to be too much rocket science here, so I believe sort -r | head -n 1 on version and (if same version) on release should provide the same result.

[Mudgen]

That's great insight into the rpm code, thanks.

Sort pipes are just never going to work without some torturous field manipulation because in the release part there are a varying number of release terms before you get to an architecture and/or distro spec.

I'm going to go with BUILDTIME, maybe validate that mtime of the vmlinux file also wins the recency race. If I were risking wrecking a working system, I wouldn't settle, but any time you're using this it will be on a system that's already broke, and rebuilding the wrong initrd won't make it any worse. Worst thing that can happen is the guy using it will have to call me for command line help.