Re: couchdb stable
On Sat, May 15, 2010 at 05:21:49PM +0100, Adam D. Barratt wrote:
> On Fri, 2010-05-14 at 17:47 -0400, Sam Bisbee wrote:
> > There's been a history of problems when upgrading between CouchDB versions that
> > we released a patch for in 0.10.1-2: I patched the init file to wait for
> > CouchDB to "really and truly" stop before continuing (@ rev1231). Without this,
> > the removal process would continue without CouchDB really being stopped,
> > causing problems. This is the same sort of idea that yaws, another erlang
> > package, uses to deal with the same issue.
> [...]
> > Here's the revision with the 0.8.0-2+lenny1 back port:
> > http://svn.debian.org/viewsvn/pkg-erlang?view=rev&revision=1231
>
> The patch itself looks fine and under the circumstances the addition of
> the procps dependency isn't unjustified (new dependencies generally set
> off SRM alarms :-)
Understood and appreciated. :-)
> The new awk dependency should not be included, however. There are two
> reasons - firstly, awk is pseudo-essential, as base-files pre-depends on
> it; secondly, and were the first reason not applicable, adding a
> dependency on awk to a stable update purely for "| awk '{print $2}'"
> would be inappropriate ("cut" from coreutils would suffice, for
> example).
Risking circular logic/discussion...
- If mawk is pseudo-essential, then should we even really need to outline it
as a dependency? My gut says "yes" because of the pseudo part.
- However, if you go up CouchDB's dependency tree (or "down" if you're a
carrot), you'll see that it already inherently depends on mawk: libmozjs2d
depends on libnspr4-0d, which depends on mawk.
So, from my understanding, even if I rewrote those scripts to use cut instead
of mawk and removed it as a dependency, we'd still be pulling in mawk. I have
no problem rewriting those scripts to use cut in a later release, but I don't
see a benefit to making those changes for this release as it doesn't appear to
change anything.
> > I would like to get this done soon so that we can release 0.11.0-1 to stable,
> > as it contains a security fix for CVE-2010-00009, and stable needs to be
> > freshened up badly.
>
> stable doesn't get "freshened up" in terms of new upstream releases
> (with a couple of notable exceptions which prove the rule).
Sorry, I didn't mean to suggest that we release directly to stable again - it
was more a commentary on how old 0.8.0 is (2 years?), and therefore stable is
missing a lot of stability and security fixes, without considering
functionality. I don't even know where users would get 0.8.0 documentation
anymore.
> A fix for CVE-2010-0009 in stable may well be appropriate,
0.10.2 may take care of this for us (see below).
> but updating
> to 0.11.0-1 is not. After ignoring changes to autotools / libtool and
> updates to the presumably-bundled Javascript libraries, the diffstat
> between the two versions is
>
> 307 files changed, 40896 insertions(+), 8269 deletions(-)
I just did a few quick diffs (also ignoring dependencies' diffs)...
diffstat between branches/0.8.0-2+lenny1 and tags/0.9.0-1
41 files changed, 405 insertions(+), 311 deletions(-)
diffstat between branches/0.8.0-2+lenny1 and tags/0.10.0-1
41 files changed, 711 insertions(+), 589 deletions(-)
diffstat between branches/0.8.0-2+lenny1 and tags/0.10.1-1
41 files changed, 727 insertions(+), 591 deletions(-)
So, thinking about getting the CVE fix into stable after 0.8.0-2+lenny1, would
it be reasonable to package 0.10.2, which has the back ported CVE fix from
upstream, and target that for the release to stable? The only changes between
0.10.1 and 0.10.2 are for the CVE fix: it was released at the same time as
0.11.0, which also has the fix, so we never packaged it. This would decrease
the delta impact on stable.
Or should we skip releasing 0.8.0-2+lenny1 to stable and go straight to 0.10.2,
negating the need for multiple releases, getting everything we want out there
(init and CVE fixes), and making some users happy? I hate putting so much
thought and effort into 0.8.0 when everything else has moved on, and I doubt
anyone really cares about it anymore.
> which is far too large for a stable update.
Hopefully the above numbers aren't too large.
Cheers,
--
Sam Bisbee
Reply to: