Re: why etc/default.d etc/local.d
On Sun, Dec 2, 2012 at 3:14 AM, Noah Slater nsla...@apache.org wrote: The premise of this question is flawed. Debian is a downstream. So are all distributions. CouchDB is designed, first and foremost, to package itself from source. That's why we create these directories for the user. Please also note that they are only created during make install and they do not exist in our source. Well they actually exists: https://github.com/apache/couchdb/tree/master/etc even if they are templates. I am not sure we need to have this init and such created by couchdb since it is the responsibility of the maintainer and only works on some distribution. Not a big deal anyway but since they won't work on all distributions, i am not sure i see the point to have them during install. - benoit On 13 November 2012 00:43, Randall Leeds randall.le...@gmail.com wrote: On Mon, Nov 12, 2012 at 3:20 PM, Jan Lehnardt j...@apache.org wrote: On Nov 13, 2012, at 00:15 , Paul J Davis paul.joseph.da...@gmail.com wrote: I'd rather leave them or remove the functionality. Hiding the config chain seems wrong. +1 on definite decisions, and +1 on keeping things as is. The functionality is to pass a config directory via the command line with the -A switch. It would be the sort of thing where the debian package would have COUCHDB_OPTIONS=-A /etc/couchdb/default.d -A /etc/couchdb/local.d in /etc/default/couchdb. On RHEL it would be /etc/sysconfig/couchdb. The change would be that running the couchdb start script by hand (not using the init script) would probably no longer assume the existence of these directories nor pass the equivalent switch implicitly. Again, I'm +0, but just wanted to make sure we were clear on what's going on. The -A flag is not in question. Only the implicit -A on these two directories and the presence of these (empty) directories in our source tree. -- NS
Re: why etc/default.d etc/local.d
The premise of this question is flawed. Debian is a downstream. So are all distributions. CouchDB is designed, first and foremost, to package itself from source. That's why we create these directories for the user. Please also note that they are only created during make install and they do not exist in our source. On 13 November 2012 00:43, Randall Leeds randall.le...@gmail.com wrote: On Mon, Nov 12, 2012 at 3:20 PM, Jan Lehnardt j...@apache.org wrote: On Nov 13, 2012, at 00:15 , Paul J Davis paul.joseph.da...@gmail.com wrote: I'd rather leave them or remove the functionality. Hiding the config chain seems wrong. +1 on definite decisions, and +1 on keeping things as is. The functionality is to pass a config directory via the command line with the -A switch. It would be the sort of thing where the debian package would have COUCHDB_OPTIONS=-A /etc/couchdb/default.d -A /etc/couchdb/local.d in /etc/default/couchdb. On RHEL it would be /etc/sysconfig/couchdb. The change would be that running the couchdb start script by hand (not using the init script) would probably no longer assume the existence of these directories nor pass the equivalent switch implicitly. Again, I'm +0, but just wanted to make sure we were clear on what's going on. The -A flag is not in question. Only the implicit -A on these two directories and the presence of these (empty) directories in our source tree. -- NS
Re: why etc/default.d etc/local.d
On Nov 10, 2012, at 12:12 , Benoit Chesneau bchesn...@gmail.com wrote: I wonder why we handle this config files in the couchdb build. It's more the responsability of the Linux, BSD distributions to maintain them. We actually just create the directories, for users to put files into, we don’t use them ourselves. Cheers Jan --
Re: why etc/default.d etc/local.d
+0 on removing them. On Mon, Nov 12, 2012 at 10:10 AM, Jan Lehnardt j...@apache.org wrote: On Nov 10, 2012, at 12:12 , Benoit Chesneau bchesn...@gmail.com wrote: I wonder why we handle this config files in the couchdb build. It's more the responsability of the Linux, BSD distributions to maintain them. We actually just create the directories, for users to put files into, we don’t use them ourselves. Cheers Jan --
Re: why etc/default.d etc/local.d
I'd rather leave them or remove the functionality. Hiding the config chain seems wrong. On Nov 12, 2012, at 5:37 PM, Randall Leeds randall.le...@gmail.com wrote: +0 on removing them. On Mon, Nov 12, 2012 at 10:10 AM, Jan Lehnardt j...@apache.org wrote: On Nov 10, 2012, at 12:12 , Benoit Chesneau bchesn...@gmail.com wrote: I wonder why we handle this config files in the couchdb build. It's more the responsability of the Linux, BSD distributions to maintain them. We actually just create the directories, for users to put files into, we don’t use them ourselves. Cheers Jan --
Re: why etc/default.d etc/local.d
On Nov 13, 2012, at 00:15 , Paul J Davis paul.joseph.da...@gmail.com wrote: I'd rather leave them or remove the functionality. Hiding the config chain seems wrong. +1 on definite decisions, and +1 on keeping things as is. Cheers Jan -- On Nov 12, 2012, at 5:37 PM, Randall Leeds randall.le...@gmail.com wrote: +0 on removing them. On Mon, Nov 12, 2012 at 10:10 AM, Jan Lehnardt j...@apache.org wrote: On Nov 10, 2012, at 12:12 , Benoit Chesneau bchesn...@gmail.com wrote: I wonder why we handle this config files in the couchdb build. It's more the responsability of the Linux, BSD distributions to maintain them. We actually just create the directories, for users to put files into, we don’t use them ourselves. Cheers Jan --
Re: why etc/default.d etc/local.d
On Mon, Nov 12, 2012 at 3:20 PM, Jan Lehnardt j...@apache.org wrote: On Nov 13, 2012, at 00:15 , Paul J Davis paul.joseph.da...@gmail.com wrote: I'd rather leave them or remove the functionality. Hiding the config chain seems wrong. +1 on definite decisions, and +1 on keeping things as is. The functionality is to pass a config directory via the command line with the -A switch. It would be the sort of thing where the debian package would have COUCHDB_OPTIONS=-A /etc/couchdb/default.d -A /etc/couchdb/local.d in /etc/default/couchdb. On RHEL it would be /etc/sysconfig/couchdb. The change would be that running the couchdb start script by hand (not using the init script) would probably no longer assume the existence of these directories nor pass the equivalent switch implicitly. Again, I'm +0, but just wanted to make sure we were clear on what's going on. The -A flag is not in question. Only the implicit -A on these two directories and the presence of these (empty) directories in our source tree.
