Re: Couchdb package
On Mon, Jan 18, 2010 at 01:18:13AM -0800, Steve Langasek wrote:
> Raphaël, if your intent here is to override the maintainer regarding this
> package split, please say so. So far, you've only made a suggestion that
> Sam consult the TC, which Sam has not stated he has any interest in doing;
> I'm offering my comments here at your request, but if you intend the TC's
> involvement to go much further, you'll need to invoke us per the
> constitution.
FWIW, I'm always open for commentary and opinions, though I haven't been around
long enough to know whether this thread should still be CC'd to TC or whether
we should take it back to our dev@.
> On Sun, Jan 17, 2010 at 12:07:56PM -0500, Sam Bisbee wrote:
> > Sorry, I didn't mean packaging in the deb/rpm/* sense but in the "it's a
> > packaged release" sense. My primary focus in their packaging is their
> > default configuration and what they support. I don't think we should be
> > changing how CouchDB behaves out of the box that its creators provide,
> > fixes and Debian-ization aside.
>
> To be explicit here (for the benefit of other TC members): the only behavior
> that's being changed in the couchdb package is to split the binary package
> into two, one (couchdb-bin) containing everything needed to run the binary
> and another separate package (couchdb) shipping the support files (init
> script, etc.) necessary to integrate this as a service which starts by
> default.
>
> Even if I accepted your premise that Debian maintainers must not diverge
> from upstream behavior in the process of integrating the software into
> Debian (which I do not),
That's very interesting to me. I base my premise on the idea that we should be
providing packages that act like they do upstream. It also has the benefit of
making it easier to work with upstream on issues, instead of beating around the
differences between upstream's and our releases. No, splitting the packages
as proposed isn't a "big" fork, but the per-user configuration would still be a
fork.
Also, I queried folks at #couchdb on freenode and it looks they don't support
per-user instances either.
Side note: I'm all for developing new features under our roof, but I think they
should be sent upstream instead of auto-included (vs. bug fixes). I'm supposed
to be packaging/maintaining the software that upstream builds, and not adding
features for the fun of it (especially when we have a very active upstream that
welcomes contributions, as opposed to a dead project or closed off dev team).
Please let me know if I'm off in this view.
> init scripts and policy decisions about when and how to start services at
> boot are absolutely *not* an upstream matter, they're a distribution matter;
> and to say that setting such a policy in a package is a fork from upstream is
> laughable.
I'm not debating that distros should modify the package to best fit in their
distro (ie., Debian-ization). However, I don't see any technical reason to do
so that would make the program run more naturally with Debian (a Debian-ization
unrelated feature request is being made that doesn't fix anything).
Worth noting, the current setup isn't breaking anything that I know of; if
someone finds that this isn't the case, then please file a bug report. Also,
David was able to make his control file work for desktopcouch, so we're not
breaking another package; again, please file bugs if I'm wrong.
I'm also not keen on officially supporting a change that IMHO isn't well
thought out and that upstream doesn't support. If people want per-user
instances, then it's going to require more than just splitting out files into
different packages.
I also believe that having one instance of CouchDB that can handle database
permissions based on system accounts is a better solution to providing per-user
functionality via per-user instances due to its ease of administration, which
is why I proposed attacking this with an auth module.
> You may decide that the policy Elliot et al. have proposed is or isn't the
> correct one for Debian to adopt, but if you're unwilling to even *consider*
> the question because "it's not upstream", I don't think you're fulfilling
> your responsibilities as a Debian package maintainer.
I think my reply rate and types of replies show that I continue to consider the
question. Please let me know if you don't think that's the case, as I would be
interested to see where I sniped, didn't consider technical details (different
than disagreeing with technical points), or whatnot as I don't think I did any
of those things and have been open through this whole discussion.
> > What if this was done as an auth module that used local system users instead of
> > a more general configuration? This would allow you to control database and
> > document access on a per-user, or per-group, basis. You would still have one
> > system wide instance, and whether it starts at boot or on demand is easily
> > taken care of by config files.
>
> By what mechanism do you intend to start the service on demand?
System service on demand would just use the init script like normal. You
could use debconf to let the user decide whether they want it to start at boot
or not (currently we do this in the init script with a conditional).
> What user owns the resulting process?
Whoever is configured in the init script.
> Who is implementing this auth module?
Me, someone else, ...? I queried #couchdb on freenode and it doesn't sound like
anyone is working on a system users based auth module - I didn't see anything
on Google or Github either. I'll probably take the time to work on this when I
can and propose it to upstream when it's sufficiently baked, assuming someone
else doesn't do it independently.
> From what I can tell, your answer to a working, widely-deployed package that
> permits on-demand user instances of couchdb is a vaporware solution with a
> hand-wavy security model. Why is this?
I don't think that was my suggestion. My question or proposition dealt with
adding functionality to CouchDB to handle auth with system users, and how this
might make the per-user instance configuration a moot point (you could have
databases be per-user and per-group). That is, I was offering another option
for discussion that I felt might give better results. I, or someone else, can
still also take the instance per-user suggestion upstream if people still want
me to.
> > You also take out the part that I always thought was odd during this
> > discussion: if even one user wants an instance, then it's more efficient
> > IMHO to start one instance than potentially starting one instance per user
> > (1 is better than N, even if N is 0).
>
> Er, no, 1 is not better than 0; 1 is much, much worse than 0 when we're
> talking about the number of couchdb instances being started by default on
> desktop systems - which was the scenario in Ubuntu that prompted the package
> split there. Couchdb had to be installed as a dependency of a desktop
> component, but should *not* be started by default because the desktop
> component in question provides optional and opt-in functionality, so by
> default a couchdb service started at boot time would be unacceptable dead
> weight.
>
> Now, this may be of much less concern in Debian, which isn't likely to be
> pulling couchdb into the default desktop any time soon, but "1 is better
> than N, even if N is 0" is certainly flawed reasoning.
Right, but you're talking about a bounded number of instances (0..1). An
unbounded set has the potential to keep going "forever" (that is, for however
many users are on the system that can use applications that would spin up an
instance).
My reasoning is that because N is not bounded that the devil you know is better
than the one you don't (or without metaphors, I would rather have 1 instance
"just in case" to support all 100 users than potentially 100 instances). I'm
not disputing that 1 > 0, but you have to account for potential: N > 1 > 0
when N is unbounded.
It's probably worth noting again that we have the ability to make the service
on demand already: we have a conditional in the init script. It should be a
small effort to make this configurable in debconf.
> > This should also scale well for distributed deployments, assuming that the
> > users' accounts are shared between machines (probably less well when sharding).
> > Instead of building an auth module for SASL, then LDAP, etc. you could just use
> > the system accounts that already support all those systems.
>
> Using system accounts certainly doesn't give you any meaningful support for
> SASL...
Sorry if I wasn't clear, I was referring to the ability to integrate other auth
systems into system accounts with pam (or whatever) and therefore into CouchDB
(SASL included). This is beneficial because it allows the use of a lot of auth
systems that currently don't have auth modules in CouchDB, thereby reusing the
wheel instead of reinventing it.
Cheers,
--
Sam Bisbee
Reply to: