For one package I maintain (qpid-cpp-server) the upstream team moved the location of the configuration file from /etc to /etc/qpid, where the other configuration files lived.
I pushed the latest update and am now getting hit with negative karma and a BZ complaining about this change.
What is SOP for when a project moves configurations? I had resisted the suggestion of having the spec move the configuration. Talking with other packagers they agreed. But simply replying to a BZ with "the file's moved, just copy yours over" and closing the BZ feels a bit aloof.
Suggestions?
On 09/25/2013 06:56 PM, Darryl L. Pierce wrote:
For one package I maintain (qpid-cpp-server) the upstream team moved the location of the configuration file from /etc to /etc/qpid, where the other configuration files lived.
I pushed the latest update and am now getting hit with negative karma and a BZ complaining about this change.
What is SOP for when a project moves configurations? I had resisted the suggestion of having the spec move the configuration. Talking with other packagers they agreed. But simply replying to a BZ with "the file's moved, just copy yours over" and closing the BZ feels a bit aloof.
Suggestions?
Add a postinstall script which copies the old config from its previous location to the new one and maybe also a symlink from the new to the old location to the new one. Exercise care with both commands so as to not overwrite existing files. I would also add a README pointing out the change. Not that people actually read but still...
On Wed, Sep 25, 2013 at 07:14:36PM +0300, Manuel Wolfshant wrote:
Add a postinstall script which copies the old config from its previous location to the new one and maybe also a symlink from the new to the old location to the new one. Exercise care with both commands so as to not overwrite existing files.
That was suggested, but I was leery of doing it since, as you mention, there's always the chance of overwriting some existing file. Especially since, if they use something like Puppet, it would mask the problem for them of updating their configuration.
I would also add a README pointing out the change. Not that people actually read but still...
True.
On 09/25/2013 06:14 PM, Manuel Wolfshant wrote:
On 09/25/2013 06:56 PM, Darryl L. Pierce wrote:
For one package I maintain (qpid-cpp-server) the upstream team moved the location of the configuration file from /etc to /etc/qpid, where the other configuration files lived.
I pushed the latest update and am now getting hit with negative karma and a BZ complaining about this change.
What is SOP for when a project moves configurations? I had resisted the suggestion of having the spec move the configuration. Talking with other packagers they agreed. But simply replying to a BZ with "the file's moved, just copy yours over" and closing the BZ feels a bit aloof.
Suggestions?
Add a postinstall script which copies the old config from its previous location to the new one and maybe also a symlink from the new to the old location to the new one. Exercise care with both commands so as to not overwrite existing files. I would also add a README pointing out the change. Not that people actually read but still...
First I agree with Kalev in this thread that this should not go to updated but only into next version of Fedora.
+1 to postinstall script, which will help easy upgrade from Fedora n to Fedora n+1
You can as well touch in file: %{_localstatedir}/lib/rpm-state/qpid-cpp-server-conf-migrated after successfull migration and if this file exist do not migrate (this can help you with old puppet configs of sysadmin).
On 09/25/2013 05:56 PM, Darryl L. Pierce wrote:
For one package I maintain (qpid-cpp-server) the upstream team moved the location of the configuration file from /etc to /etc/qpid, where the other configuration files lived.
I pushed the latest update and am now getting hit with negative karma and a BZ complaining about this change.
What is SOP for when a project moves configurations? I had resisted the suggestion of having the spec move the configuration. Talking with other packagers they agreed. But simply replying to a BZ with "the file's moved, just copy yours over" and closing the BZ feels a bit aloof.
Suggestions?
I would leave the new qpid-cpp version to F20+ only. People can deal with changes during distro upgrades -- they know that stuff might have changed and can manually fix up any issues that the migration might have caused. They are also more likely to have taken backups and other precautions, so that if your rpm overwrites an other config file during a distro upgrade, it's not the end of the world for them.
Doing major configuration file reorganization in a stable Fedora release, when people are minding their own business and not looking out for changes, might not be appreciated by users.
See also http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases
On Thu, Sep 26, 2013 at 01:14:11AM +0200, Kalev Lember wrote:
On 09/25/2013 05:56 PM, Darryl L. Pierce wrote:
For one package I maintain (qpid-cpp-server) the upstream team moved the location of the configuration file from /etc to /etc/qpid, where the other configuration files lived.
I pushed the latest update and am now getting hit with negative karma and a BZ complaining about this change.
What is SOP for when a project moves configurations? I had resisted the suggestion of having the spec move the configuration. Talking with other packagers they agreed. But simply replying to a BZ with "the file's moved, just copy yours over" and closing the BZ feels a bit aloof.
Suggestions?
I would leave the new qpid-cpp version to F20+ only. People can deal with changes during distro upgrades -- they know that stuff might have changed and can manually fix up any issues that the migration might have caused. They are also more likely to have taken backups and other precautions, so that if your rpm overwrites an other config file during a distro upgrade, it's not the end of the world for them.
Doing major configuration file reorganization in a stable Fedora release, when people are minding their own business and not looking out for changes, might not be appreciated by users.
See also http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases
That's a very good point, one I hadn't considered. For future updates I'll keep major releases to n+1 only and only backport on requests.
packaging@lists.fedoraproject.org
-
Darryl L. Pierce -
Kalev Lember -
Manuel Wolfshant -
Miroslav Suchý