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 d...@. > 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
