On 28/06/15 02:17, Joseph L. Casale wrote:

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

On 28/06/15 03:06, Joseph L. Casale wrote:

Hi Joseph,

Well normal convention would be if you replace then the old one gets appended with .rpmsave, if you are not replacing then the new one gets appended with .rpmnew.

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

On the other hand, check this out: https://www.redhat.com/promo/summit/2010/presentations/summit/opensource-for...

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 17:50 schrieb John R Pierce pierce@hogranch.com:

On 6/27/2015 5:38 PM, Anand Buddhdev wrote:

...

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.

why doesn't the config file have the version in it ? not having that makes your whole system error prone.

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.

-- LF

On 6/28/2015 2:26 PM, Anand Buddhdev wrote:

On 28/06/15 17:50, John R Pierce wrote:

...

why doesn't the config file have the version in it ? not having that makes your whole system error prone.

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

system { setting1 value1; setting2 value2; }

interfaces { iface1; iface2; }

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

system: 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 format.

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.

On 29/06/15 01:07, Kahlil Hodgson wrote:

On 29 June 2015 at 07:37, John R Pierce pierce@hogranch.com wrote:

...

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).

Anand

On 06/28/2015 05:11 PM, Anand Buddhdev wrote:

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).

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.