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 ticket. (Good to have you on the list, Laszlo. Are you also subscribed to annou...@couchdb.apache.org? We will only use that for release announcements and security disclosures.) On 22 June 2013 00:45, Laszlo Boszormenyi (GCS) <g...@debian.hu> 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 dist.apache.org > > > > 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 > > -- NS
