couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: State of Debian Packaging
Date Wed, 26 Jun 2013 13:23:58 GMT
My preference is that we keep packaging out of couchdb.git. I have seen on
other projects that source releases have to be cancelled mid-vote because
of some bug in the Debian packaging. Our releases are painful enough, so
I'd rather avoid this.

What I'd suggest is that you request a new Git repos and put in there. We
could have couchdb-deb.git, couchdb-rpm.git, couchdb-win.git,
couchdb-mac.git. Whatever really. Git repos are cheep!

If you want to request one, just send an email to the list with a
[PROPOSAL] tag (i.e. "This is a concrete proposal with consensus in effect
and a 72 hour time limit") wait 72 hours, and then open an Infra JIRA

(Good to have you on the list, Laszlo. Are you also subscribed to We will only use that for release
announcements and security disclosures.)

On 22 June 2013 00:45, Laszlo Boszormenyi (GCS) <> wrote:

> On Thu, 2013-06-20 at 10:53 -0700, Randall Leeds wrote:
> > I saw that my packaging efforts came up in the IRC meeting yesterday
> > and I wasn't there to report.
> >
> > Here's what's done:
> >  - Split the packaging into couchdb and couchdb-bin as Ubuntu did
> downstream
>  Will check why it makes sense.
> > You can try it by installing git-buildpackage, cloning the pkg-couchdb
> > repository, using git-dch to create a new debian/changelog entry for
> > 1.3.1, and running git-buildpackage.
>  Please note that previously I couldn't build couchdb 1.3.0 . The Erlang
> version in the Debian archives is (was?) too new for it. Hope it's
> solved with 1.3.1 then. Even if I was forcing it to build, Futon was
> failing due to some incompatibility between Erlang versions. Is it still
> supported?
> > Here's what remaining to be done, based on my notes from previous
> > conversations with Laszlo and others:
> >  - Use system libyajl-dev
> >  - Use system libspeedy-dev
> >  - Use system libjs-json
> >  - Use system libjs-coffeescript
> >  - Publish to
> >
> > The first 4 are Debian policy issues.
>  Sure, it should be a policy for everyone. Meaning don't do code
> duplication but use the ones from the system. If one has a security fix,
> then it's fixed for all dependent applications. But if someone embeds
> them and those don't get the security fix, you will remain affected.
> Sometimes blindly, as you may not realize that the application contains
> other libraries.
> > Laszlo: If you already have a repo for this work anywhere that you
> > would prefer I use I would be glad to collaborate there.
>  Not yet, but we can discuss it in private.
> On Thu, 2013-06-20 at 14:33 -0700, Randall Leeds wrote:
> > In the case of the Debian packaging, I'd like to not have it in the
> > main source tree, since that creates pain if downstream packagers
> > decide to diverge from our way of doing it.
>  It's not a problem for me. The 'new' source package format (3.0 ie
> quilt) works this around. Easily as it gets the upstream tarball,
> unpacks it and deletes debian/ from the tree and applies my debian/
> subdir. Thus I don't even see if upstream has debian/ or not.
> Laszlo/GCS


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message