couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: why etc/default.d & etc/local.d
Date Mon, 03 Dec 2012 10:38:38 GMT
On Sun, Dec 2, 2012 at 3:14 AM, Noah Slater <nslater@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.leeds@gmail.com> wrote:
>
> > On Mon, Nov 12, 2012 at 3:20 PM, Jan Lehnardt <jan@apache.org> wrote:
> >
> > >
> > > On Nov 13, 2012, at 00:15 , Paul J Davis <paul.joseph.davis@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message