couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Micah Anderson <>
Subject Re: Packaging 2.0
Date Thu, 29 Jan 2015 18:14:41 GMT
Paul Davis <>

> Its a bit of a mish mash for the time being. If you let us know what
> things are needed to help with packaging I'm sure we'll be able to do
> most of what you need. Although I think the easiest approach at this
> time would be to write a script that installs off a release rather
> than trying to write up a build system that does either a release or a
> Debian style install. The project decided to move to the Erlang
> approach to packaging so that'll be the best long term for everyone
> involved I think.
> To do that, run:
> $ ./configure
> $ make dist
> And then look at the rel/couchdb directory for the output.

Ok, I solved my earlier problem, now I was able to do the make dist.

What I've tried to do is to simulate a release by generating a tarball
after doing a ./configure. The tarball does not contain any .git
directories (as this would not be a good thing to have in a release
tarball), and this should be something that would be self-contained and
I could build.

However, it seems that the way the rebar configuration is done, this
will not work, because building is going to require git when it does:
'do sh(git describe --always --tags)' and then its going to do a remote
git operation to look for newer versions of things. This wont work for a
package, it needs to build without querying remote git repositories and
pulling down new data.

Even when doing a 'make clean' that will invoke 'rebar -r clean' which
will try to do git operations. This fails because there is no git

I dont know rebar at all, but maybe there might be a way to change the
rebar.config.script to not do this? Or what about some kind of exclude
filter to the reltool configuration for the release?

Until this is resolved, I'm a bit stuck!

Thanks for your help,

View raw message