couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laszlo Boszormenyi (GCS)" <...@debian.hu>
Subject Re: State of Debian Packaging
Date Fri, 21 Jun 2013 23:45:13 GMT
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


Mime
View raw message