One option: the package post-install could try and track if it's upgrading and rename the config file for us? I'm unsure what the DEB vs. RPM difference in capabilities are here, just adding as a possible idea pile.

Two things can happen during the upgrade if we change %{_sysconfdir}/recap to %{_sysconfdir}/recap.conf in the spec file.

1. If the file is unmodified, /etc/recap is removed and /etc/recap.conf is created. Effectively a simple move.
2. If the file has been modified, /etc/recap is renamed to /etc/recap.rpmsave and /etc/recap.conf is created. Requires manual merging of those two files (similar to a normal .rpmnew file).

While we are able to add logic to %post to attempt to do more, it is non-standard and I would recommend we avoid it. Keep it simple.

There are references to load configs from multiple locations, quite likely that needs to be removed as well:

• recap - https://github.com/rackerlabs/recap/blob/development/src/recap#L576-L589
• recaplog - https://github.com/rackerlabs/recap/blob/development/src/recaplog#L272-L287

Alright, I've created #137 that should now give hints that the new location should be /etc/recap.conf to avoid the sudden change I'm still taking precedence to the old config in case is found: /etc/recap but on the next release that will be dropped.

The first stage has been fixed - #137 (comment)

It is expected that /etc/recap references will be completely out of recap by 1.5.0

Changing milestone to 1.4.0 for the 2nd stage.

#151 is a PR to be included in 1.4.0 This is continuation of the solution of this issue.

From: #137 (comment)

• 1.4.0:
  • Create awareness of /etc/recap but now make /etc/recap.conf to take precedence.
  • If /etc/recap.conf is missing but /etc/recap is found the latter is read.

Package-wise(RPM) it will not be any major change as described in #137 (comment)

Closing this issue, releasing in 2.0.0, Fix on #182