Old And New Package Version Numbers During RPM Update

Home » CentOS » Old And New Package Version Numbers During RPM Update
CentOS 14 Comments

Hi CentOS folk,

In an RPM post-install script, is it possible to know the previous version number, and the new version number of a package if it’s an update?

I need to know this, because for a certain package, if updating from version 1.x to 2.x, I need to run a program to convert the config file of the package from version 1.x format to version 2.x format.

I’ve looked at SPEC file documentation, but haven’t found anything relevant.



14 thoughts on - Old And New Package Version Numbers During RPM Update

  • Your script within the rpm should have the logic. Clearly if you know how to update it, you know how to identify if it needs updating.


  • Thanks Joseph. I am aware of this option, but it would be only a last resort, because checking the format of the config file is error-prone.

    I would prefer RPM to tell me the old and new version numbers, so my question still stands.

    Regards, Anand

  • Hi Joseph,

    I’m also aware of this, but it’s not what I need :)

    This is a very interesting presentation. I had no idea about trigger scripts. I’m going to play around with them, and see if they can help me solve my case.

    Thank you for the link!

    Regards, Anand

  • Am 28.06.2015 um 01:59 schrieb Anand Buddhdev :

    OLDVER=$(rpm -q –qf ‘%{VERSION}\n’ | sort -V |head -1)

  • Am 28.06.2015 um 17:50 schrieb John R Pierce :

    normally config files have semantics that lets understand the parser the content. So, two accepting rules (regex) could be used to identify the config type of the file.

  • Perhaps I wasn’t clear. Version 1 of the package uses a config file that looks like this:

    system {
    setting1 value1;
    setting2 value2;

    interfaces {

    Version 2 of the package has switched to a YAML-based syntax, so the config file needs to look like this:

    setting1: value1
    setting2: value2

    So, I need to be able to program the RPM so that when upgrading from 1.x to 2.x, it triggers the conversion utility that converts from v1 to v2


  • so a regex looking for “system:” vs “system {” should nicely delineate these. I dunno, I might even put that into the conversion utility and have it just quit if the file is already in the new format, and always run it.

  • ​+1 for the idempotent approach. IMHO much more robust. Also consider what will happen if someone does a ‘yum downgrade’ on the package or a dependency — you might want to allow the conversion to go both ways or at least complain appropriately.


  • Yep. I’ve already considered this approach, but I avoid regexes as much as possible. They’re great for some work, but they can inadvertently match too much or fail (for example if the “system” keyword and the opening brace are on different lines). You see where I’m going? But, this is a digression…

    I also prefer an idempotent approach, and I’m already talking to the authors of this specific package (knot dns), about making their knot1to2
    utility idempotent, so that it’s always safe to run it.

    However, one problem is that nothing can handle downgrades. The v2
    config format is a superset of the v1 format, and while not impossible, it’s very hard to go back. There is no reverse knot2to1 utility.

    I’d like to thank everyone for the various suggestions. I’m going to place with them and see which one works out best.

    Finally, as an aside, I’d like to mention that upgrading my own systems is easy, because I have control over them. My motivation for asking this question was for making an EPEL package that can work for most people without breaking their installations (especially if they have unattended yum updates, like with yum-cron).


  • Am 29.06.2015 um 02:11 schrieb Anand Buddhdev :

    that is exactly what regex can do for you. it confirms the “language”
    of the config file, unattached from new lines or space characters. Sure, the expression itself is more “complicated” … (a combination of tools is also possible eg. tr, awk, sed, grep)


  • Bear in mind that one of the reasons people use stable distributions like RHEL/CentOS is that what you are suggesting does not happen. Major changes should not be made during a platforms support lifetime.

    PostgreSQL is a good example for the best way to handle this. RHEL 5
    was originally released with PostgreSQL 8.1. When 8.4 was released, it had features that made it highly desirable, but it wasn’t compatible with the existing data files. The new version was released as PostgreSQL84 so that admins who wanted it could upgrade manually, but the upgrade would not happen automatically.

    Maybe the best thing to do is release knotdns2 and avoid surprising admins with changes they need to prepare for.