How to handle a config(noreplace) file that needs to be updated

[Robert-André Mauchin]

Hello,

I have a project for which the config file (toml) has been significantly 
changed, notably renamed sections. As such some older config parameters 
won't work anymore.
However the current config file can't be overwritten because of 
config(noreplace) directive. How do I recommend my users to move to the 
new config format?

Best regards,

Robert-André

[Miroslav Suchý]

Dne 03. 01. 21 v 20:16 Robert-André Mauchin napsal(a):
>  
>  I have a project for which the config file (toml) has been significantly changed, notably
> renamed sections. As such some
>  older config parameters won't work anymore.
>  However the current config file can't be overwritten because of config(noreplace)
> directive. How do I recommend my users
>  to move to the new config format? 
1) If their system is Ansible managed (should be), they simple deploy new config.

2) If they manage the system manualy then
  rpmconf -a
should be run after each (major) update.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

[Neal Gompa]

On Sun, Jan 3, 2021 at 3:01 PM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
>  Dne 03. 01. 21 v 20:16 Robert-André Mauchin napsal(a):
>  >
>  > I have a project for which the config file (toml) has been significantly changed,
> notably renamed sections. As such some
>  > older config parameters won't work anymore.
>  > However the current config file can't be overwritten because of
> config(noreplace) directive. How do I recommend my users
>  > to move to the new config format?
>
>  1) If their system is Ansible managed (should be), they simple deploy new config.
>
>  2) If they manage the system manualy then
>    rpmconf -a
>  should be run after each (major) update.
>  
Another option is to add a pretrans scriptlet to rename the file to
force the new config to be installed in place.




--
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Robert-André Mauchin wrote:
>  I have a project for which the config file (toml) has been
> significantly
>  changed, notably renamed sections. As such some older config parameters
>  won't work anymore. 
Tools like sed, ed, awk etc. in %post scriptlets can do wonders.

        Kevin Kofler

[Nico Kadel-Garcia]

On Sun, Jan 3, 2021 at 8:45 PM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Robert-André Mauchin wrote:
>  > I have a project for which the config file (toml) has been significantly
>  > changed, notably renamed sections. As such some older config parameters
>  > won't work anymore.
>
>  Tools like sed, ed, awk etc. in %post scriptlets can do wonders.
>
>          Kevin Kofler 
So can *not touching someone else's config files*. If I've gone to the
trouble of locally or manually editing a config file, I generally
don't appreciate your package manually tweaking it  inside your RPM
%post scripts in an unpredictable fashion. Replace it, or don't, but
don't get cutesy with it. This is the problem with authconfig: it
overrides local tuning.

[Kevin Kofler]

Nico Kadel-Garcia wrote:
>  So can *not touching someone else's config files*. If I've
> gone to the
>  trouble of locally or manually editing a config file, I generally
>  don't appreciate your package manually tweaking it  inside your RPM
>  %post scripts in an unpredictable fashion. Replace it, or don't, but
>  don't get cutesy with it. This is the problem with authconfig: it
>  overrides local tuning. 
Well, if upstream breaks config file compatibility, there are only 3 things 
the packager can do:
1. retain your config file unchanged. The application will no longer start
   up until you fix the config file.
2. delete or move the config file. That loses all your settings.
3. try to fix the config file automatically (and keep a backup). That should
   normally allow the application to start without losing your settings. It
   may or may not be practical depending on how significant the changes are.

The previous replies suggested option 2, which is exactly "overriding local 
tuning". I suggested option 3, which, if possible, is less destructive.

But of course, I would first of all blame the upstream application for not 
providing a migration path for existing settings!

        Kevin Kofler

[Robert-André Mauchin]

On 1/4/21 2:44 AM, Kevin Kofler via devel wrote:
>  Robert-André Mauchin wrote:
> > I have a project for which the config file (toml) has been significantly
> > changed, notably renamed sections. As such some older config parameters
> > won't work anymore.
>  
>  Tools like sed, ed, awk etc. in %post scriptlets can do wonders.
>   
I would do that but the cange are too extensive. And some config file 
got renamede I'm not sure how to handle that yet.

[Fabio Valentini]

On Sun, Jan 3, 2021 at 8:16 PM Robert-André Mauchin <zebob.m(a)gmail.com&gt; wrote:
>  Hello,
>
>  I have a project for which the config file (toml) has been significantly
>  changed, notably renamed sections. As such some older config parameters
>  won't work anymore.
>  However the current config file can't be overwritten because of
>  config(noreplace) directive. How do I recommend my users to move to the
>  new config format?
>
>  Best regards,
>
>  Robert-André 
The simplest solution might be to only provide the update with the
breaking change in rawhide / f34, and put a change about the new
config file format into the release notes. Such breaking changes are
to be expected when doing major upgrades, and people should read the
release notes if they have custom configs they care about.

Fabio