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. 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), 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. 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. > 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? What user owns the resulting process? Who is implementing this auth module? 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? > 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. > 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... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature