On Mon, 15 Mar 2004, Travis Hamrick wrote:
> I am creating an rpm for a system that must update files that can
> contain site-specific customizations. Here are some questions I am
> having difficulty resolving:
>
> 1) I would like to know on update what version I am updating from. My
> project is somewhat experimental, so data the user has saved *may* have
> to undergo some conversion, depending on what version they are updating
> from.
>
> I need to know how to query rpm in the %pre script and then use the
> information from that query in the post script to determine if
> conversions need to be run:
>
You can just do that if its rpm 4.1 or greater (this number may be lower,
someone correct me please). That being said, a better way IMO is to
actually version the config file format. For instance if your config
file was a list of key values (I know simple, but you get the point),
then you could have a key called configVersion or something like that:
configVersion = 1.0
key1 = yada yada
Once you have your configs versioned, then you can detect the version
of the config on the system, and then convert it to the target version.
How you do that conversion is up to you.
Cheers...james
> %pre
> OLDVERSION=`rpm -q --qf '%%{VERSION}' %{name}`
> %define OldVersion $OLDVERSION
> echo "about_to_install"
> echo %{OldVersion}
> %post
> echo "post install"
> echo %{OldVersion}
>
> This doesn't work. I am guessing it is because macros are expanded
> before the script is run. How can I save a value in one script to use
> in another?
>
>
>
> 2) The other question I have is that I have some configuration files
> which contain default data at the top of the file, and then a section at
> the bottom of the file where the data can be redefined for site-specific
> customizations. I understand that I need to list them as config files,
> and that the old files will be saved with the .rpmsave extension if
> modified. My question is, what is the most reliable way of getting the
> path of all files that have been saved at install, so I can run them
> through a merging process whereby the defaults from the new version can
> be merged with the user-customizations from a previous version?
>
One way of handling this is to mark the config files with noreplace:
%config(noreplace) /etc/blah
And then in your %post install, if its an upgrade, convert it (having it
marked with a version is a real good idea here too). The noreplace will
mean that the config does not get replaced on an upgrade, so whatever the
user puts in it is safe. If you don't do this, then you have to grab
there stuff from the backup of the config made by rpm; I suppose its a
matter of taste, so do whatever works for you.
Cheers...james
>
> Thanks
>
> Travis
>
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/rpm-list
>
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
