CentOS - Jun 2015 - Old and new package version numbers during RPM update

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

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

On the other hand, check this out:
https://www.redhat.com/promo/summit/2010/presentations/summit/opensource-for-it-leaders/thurs/pwaterma-2-rpm/RPM-ifying-System-Configurations.pdf

Seems you are in luck, you can infer what exists by virtue of the
order upgrades are installed.

Hth,
jlc

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-it-leaders/thurs/pwaterma-2-rpm/RPM-ifying-System-Configurations.pdf
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

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.



-- 
john r pierce, recycling bits in santa cruz

Am 28.06.2015 um 17:50 schrieb John R Pierce <pierce at
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 28/06/15 17:50, John R Pierce wrote:
> 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.
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.

Anand