[Pkg-erlang-devel] CouchDB packaging updates

[Sam Bisbee]

On Tue, Nov 10, 2009 at 11:11:43AM +0300, Sergei Golovan wrote:
> On Tue, Nov 10, 2009 at 12:54 AM, Elliot Murphy <elliot at canonical.com> wrote:
> > On 11/09/2009 04:31 PM, Sam Bisbee wrote:
> >> Well, why have it start at boot if it's unwanted? And can't desktopcouch (or
> >> whatever) just run the init script if couchdb isn't running, thereby creating
> >> an on demand service?
> >>
> >
> > The point of splitting out the couchdb-bin package is so that the init
> > script isn't installed, and couchdb is not started on boot.
> 
> It's very strange point as for me. Either you want to use the service,
> so it should be started, or you don't, so don't install it.

Agreed. Also, even if you have couchdb installed and don't want to use it (for
shame!), then you can uninstall it, remove the init script, re-configure to not
start couchdb on boot, etc.

[snip]
> I would say that if you want to install couchdb on a per-user basis it
> must satisfy the following conditions:
> 
> 0) It must be configurable by user in his home directory and not by
> root it /etc. It must be usable in multiple user environment (so two
> couchdbs running by two different users must not conflict);
> 1) It must be really personal, another user must not be able to
> connect to it and store or retrieve data;
> 2) any application which wants to use couchdb must be able to use an
> existing instance if any.

Agreed with these three items, and I would include that they shouldn't be
allowed to do I/O with network devices (or anything else external that the user
doesn't own).

> But achieving these goals does look as forking to me. Simply removing
> init script isn't sufficient.

Yup.

> > Getting back on topic, there is a genuine desire from people writing
> > applications which use couchdb (Ubuntu One) to be able to install the
> > couchdb binaries without getting a systemwide couchdb booted. If there
> > is a better way to provide this capability in the packaging than
> > splitting into two binary packages, then I'd love to hear it.
> 
> Debian is not UbuntuOne. And having one system-wide database service
> looks better to me than launching another one on start of any
> application. Moreover, the upstream doesn't provide per-user
> customization of couchdb.

Agreed, this should be handled upstream. It's a fundamental design decision in
the application.

Additionally, I have no problem making certain considerations for downstream
packages and Debianization, but everything else should get kicked upstream.
Especially when there is so much active development and support (the project
isn't exactly dead).

> > Another approach that was considered was using a flag in a config file
> > to determine whether or not the systemwide couchdb should be started
> > when the init script runs. That doesn't totally solve this though, as
> > then there is a debate over what the default setting should be. Even
> > with such a setting in the upstream init script and config file, I don't
> > know how to express a dependency on couchdb to say "Desktopcouch depends
> > on couchdb but please don't boot the system instance by default unless
> > someone else requested it".
> 
> Why can't desktopcouch use a system-wide couchdb service?

I think his point is around the need to start couchdb at boot if you want to do
on demand, but we've covered that.

> > This isn't in any way a fork from upstream. Upstream doesn't provide the
> >  debian packaging in the tarball they release (yes, I'm ignoring that
> > Noah is awesome and maintained the package so far ;), the packaging is
> > added by debian maintainers. This is purely about splitting the binary
> > packages so that they are useful in the widest variety of situations.
> 
> It is essentially a fork because you have yo add (remove init script,
> actually) something which is unexpected by the upstream.
> 
> >
> >>
> >> p.s. Am being slowed down by svn/ssh issues in the virtual box when connecting
> >> to alioth.
> >>
> >
> > Strange! It's been a long time since I worked with svn, I've been having
> > to type my passphrase for every operation, even log. Otherwise it's been
> > working fine.
> 
> It's possible to add a public key in alioth web-interface (at account
> management) and use ssh-agent instead of always typing your password.

Yeah, that's what I've been using. There was some hostname issues that I got
resolved last night, taking up way too much time. *phew*

-- 
Sam Bisbee