At present qpid installs config files thus: jross@localhost qpid$ l -d /etc/qpid* -rw-r--r--. 1 root root 1021 Nov 12 13:28 /etc/qpidd.conf drwxr-xr-x. 2 root root 4.0K Nov 23 11:13 /etc/qpid jross@localhost qpid$ l -d /etc/qpid/*.conf -rw-r--r--. 1 root root 929 Nov 12 13:28 /etc/qpid/qpidc.conf I propose instead: /etc/qpid/deamon.conf (was /etc/qpidd.conf) /etc/qpid/client.conf (was /etc/qpid/qpidc.conf) The old locations should be supported as fallbacks. Note that the daemon/client terminology is in keeping with the dir names used for modules: /usr/lib64/qpid/daemon/acl.so /usr/lib64/qpid/daemon/replicating_listener.so
New proposal (a little less disruptive): /etc/qpid/qpidd.conf (was /etc/qpidd.conf) [qpidc.conf is already in the right place] For this to be complete, we need to add logic to the rpm to migrate config from the old qpidd.conf location to the new one.
(In reply to Justin Ross from comment #1) > New proposal (a little less disruptive): > > /etc/qpid/qpidd.conf (was /etc/qpidd.conf) > [qpidc.conf is already in the right place] > > For this to be complete, we need to add logic to the rpm to migrate config > from the old qpidd.conf location to the new one. I don't think we want to have the specfile do things like moving around files that the user has edited. If the user has modified the file then when the upgrade occurs the file should get left behind (and possibly with it renamed with "-rpmsave" appended to it). If the user didn't modify the file then no problem, the old file will just get deleted. In either case the new config file will land in /etc/. If the user has modified their original file then they'll be able to copy those changes over. But you don't want to have the specfile itself trying to copy those files around.
I'm not sure that just renaming the old configuration file will adequately indicate to the user that the configuration file location has changed. Is there some way we can indicate that all the use really has to do is move the old file to the new location? It's not like there is any real migration to be done the file format is unchanged it's just in a different location. So there's no danger we will screw up the configuration in the move. I'd suggest that moving the old config (if it has been changed) from /etc/qpidd.conf->/etc/qpid/qpidd.conf and installing the example as /etc/qpid/qpidd.conf.rpmnew would be a low risk strategy. You could also leave it as /etc/qpidd.conf.rpmsave as well I suppose (but I think that would be a little confusing myself) Daryl, is there a specific reason you are opposed to moving the existing configuration?
(In reply to Andrew Stitcher from comment #3) > I'm not sure that just renaming the old configuration file will adequately > indicate to the user that the configuration file location has changed. Is > there some way we can indicate that all the use really has to do is move the > old file to the new location? It's not like there is any real migration to > be done the file format is unchanged it's just in a different location. So > there's no danger we will screw up the configuration in the move. > > I'd suggest that moving the old config (if it has been changed) from > /etc/qpidd.conf->/etc/qpid/qpidd.conf and installing the example as > /etc/qpid/qpidd.conf.rpmnew would be a low risk strategy. > > You could also leave it as /etc/qpidd.conf.rpmsave as well I suppose (but I > think that would be a little confusing myself) > > Daryl, is there a specific reason you are opposed to moving the existing > configuration? The renaming of files, etc. is handled by the packaging software outside of the specfile itself. I spoke with a few people in the #fedora-devel channel when this first came up and the overwhelming response was "don't use the spec to move configuration files around; leave any changes in place and let the sysadmin move the changes themselves". That way if, for example, they've puppetized their configs they'll know to update their puppet configuration. Or if they're using some other means to automate updating configurations they're on top of it. If we move it for them they may not be aware until their system breaks for some reason.
*** Bug 678165 has been marked as a duplicate of this bug. ***
We're going to with Darryl's recommendation (that is, leave it alone), so this one can be considered dev complete. -> MODIFIED
rhel 6.4 x84_64 Updated from qpid-cpp-server-0.18-14.el6.x86_64 to qpid-cpp-server-0.22-11.el6.x86_64 rhel 6.4 i696 Updated from qpid-cpp-server-0.18-14.el6.i686 to qpid-cpp-server-0.22-11.el6.i686 Verified - new /etc/qpid/qpidd.conf file is installed - broker now uses new qpidd.conf and not old one - qpidc.conf is still present and existing changes are still present
I would change the doc text result to read: Result: The config file is installed to /etc/qpid/qpidd.conf, and the broker now uses this new qpidd.conf file. The old qpidd.conf file may be preserved as /etc/qpidd.conf.rpmsave, if there were any local changes made, to ensure any configuration can be migrated into the new file manually.
I still think the text is incorrect: "The old qpidd.conf file is preserved in /etc/qpidd.conf to ensure any configuration can be migrated into the new file manually." should really say "The old qpidd.conf file is preserved _as /etc/qpidd.conf.rpmsave, if there were any local changes made,_ to ensure any configuration can be migrated into the new file manually."
Oh, sorry, I missed your new text. This should go into the doc text field, not into a comment. (In reply to Darryl L. Pierce from comment #9) > I still think the text is incorrect: > > "The old qpidd.conf file is preserved in /etc/qpidd.conf to ensure any > configuration can be migrated into the new file manually." > > should really say > > "The old qpidd.conf file is preserved _as /etc/qpidd.conf.rpmsave, if there > were any local changes made,_ to ensure any configuration can be migrated > into the new file manually."
(In reply to Justin Ross from comment #10) > Oh, sorry, I missed your new text. This should go into the doc text field, > not into a comment. Done.
I'm not sure why this was changed back to the previous, incorrect text. RPM configuration files are saved with ".rpmsave" added to the end, per my previous change to the doctext.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1296.html