couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
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
ticket.

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


On 22 June 2013 00:45, Laszlo Boszormenyi (GCS) <gcs@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

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