Re: mongodb.conf rename
Honza Horak píše v St 04. 02. 2015 v 11:58 +0100:
On 02/02/2015 05:01 PM, Miloslav Trmač wrote:
Hello,
in Fedora Rawhide there is a new major version of mongoDB 2.6. With this
new version names of mongoDB configuration files will be changed - to
reflect names used in upstream rpms
(http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/RPMS/ )
mongodb.conf - mongod.conf
mongodb-shard.conf - mongos.conf
In Fedora mongodb.conf is used from version 12.
If this change should be a problem, please contact me...
Is it possible to do something (write RPM scriptlets, or perhaps ship
symlinks) to make this transparent and effortless to users?
Let's look at it closer.. First, we need to do all the magic only if
previous version is 2.6.
One idea is that we could use %pre script and do the following in it:
If /etc/mongodb.conf is there (that means we upgrade from 2.4), move it
to /etc/monogd.conf and create a symlink /etc/mongodb.conf
/etc/mongod.conf
There is one issue I see with this way -- generally when we bring new
content during update and the config file hasn't changed, rpm replaces
the content and creates config.rpmnew otherwise. The solution above
wouldn't behave like this.
Another idea is that we can just ship new config and let the old one
either be backed-up (into config.rpmsave in case it has been changed)
or removed. Then in case /etc/mongodb.conf.rpmsafe exists, its content
could be copied to /etc/mongod.conf, while the original /etc/mongod.conf
would be copied into /etc/mongod.conf.rpmnew. Hopefully, that should
handle the same user experience as when user upgrades ordinary.
With the rename of mongodb.conf and mongodb-shard.conf there are also
changes in /etc/sysconfig/mongod and /etc/sysconfig/mongos. In these
files there is mainly one option which determines config file and these
files are marked as %config(noreplace). So it complicates upgrade...
1. /etc/sysconf/mongod changed /etc/mongodb.conf changed
- use these changed files with same names
2. /etc/sysconf/mongod changed /etc/mongodb.conf original
- use changed mongod file and rename mongod.conf back to mongodb.conf
1. /etc/sysconf/mongod original /etc/mongodb.conf changed
- use new mongod file and rename changed mongodb.conf to mongod.conf
2. /etc/sysconf/mongod original /etc/mongodb.conf original
- use new files
And the same for /etc/sysconfig/mongos and mongodb-shard.conf...
I have implemented this in %triggerpostun server -- %{name}-server
2.6.7-3 (
http://pkgs.fedoraproject.org/cgit/mongodb.git/tree/mongodb.spec#n291 )
But it is quite complicated. Is it required to check changes in
sysconfig files? Not enough to check only config files?
Or what else should be done?
Thanks,
Marek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mongodb.conf rename
On 02/02/2015 05:01 PM, Miloslav Trmač wrote: Hello, in Fedora Rawhide there is a new major version of mongoDB 2.6. With this new version names of mongoDB configuration files will be changed - to reflect names used in upstream rpms (http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/RPMS/ ) mongodb.conf - mongod.conf mongodb-shard.conf - mongos.conf In Fedora mongodb.conf is used from version 12. If this change should be a problem, please contact me... Is it possible to do something (write RPM scriptlets, or perhaps ship symlinks) to make this transparent and effortless to users? Let's look at it closer.. First, we need to do all the magic only if previous version is 2.6. One idea is that we could use %pre script and do the following in it: If /etc/mongodb.conf is there (that means we upgrade from 2.4), move it to /etc/monogd.conf and create a symlink /etc/mongodb.conf /etc/mongod.conf There is one issue I see with this way -- generally when we bring new content during update and the config file hasn't changed, rpm replaces the content and creates config.rpmnew otherwise. The solution above wouldn't behave like this. Another idea is that we can just ship new config and let the old one either be backed-up (into config.rpmsave in case it has been changed) or removed. Then in case /etc/mongodb.conf.rpmsafe exists, its content could be copied to /etc/mongod.conf, while the original /etc/mongod.conf would be copied into /etc/mongod.conf.rpmnew. Hopefully, that should handle the same user experience as when user upgrades ordinary. Just thinking laudly, so there may be some drawbacks or better solutions. Honza [1] http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mongodb.conf rename
Hello, in Fedora Rawhide there is a new major version of mongoDB 2.6. With this new version names of mongoDB configuration files will be changed - to reflect names used in upstream rpms (http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/RPMS/ ) mongodb.conf - mongod.conf mongodb-shard.conf - mongos.conf In Fedora mongodb.conf is used from version 12. If this change should be a problem, please contact me... Is it possible to do something (write RPM scriptlets, or perhaps ship symlinks) to make this transparent and effortless to users? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
mongodb.conf rename
Hi, in Fedora Rawhide there is a new major version of mongoDB 2.6. With this new version names of mongoDB configuration files will be changed - to reflect names used in upstream rpms (http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/RPMS/ ) mongodb.conf - mongod.conf mongodb-shard.conf - mongos.conf In Fedora mongodb.conf is used from version 12. If this change should be a problem, please contact me... Thanks, Marek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
