couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Packaging 2.0
Date Thu, 22 Jan 2015 21:12:44 GMT
On Thu, Jan 22, 2015 at 1:30 PM, micah anderson <> wrote:
> Hello,
> I'm working on making a Debian package of couchdb-2.0. I figure now is
> the time to start working on this, before it is released. Also I need
> this version for some development work I'm involved in. Right now, the
> 1.5 version of couchdb is in Debian, I worked a lot on getting the 1.6
> version updated there, and was 90% finished, but then I decided it was
> better to wait for 2.0.
> I have a few questions and issues that I'd like to work out, I'll try
> not to overwhelm you and instead just ask a few at a time.
> First of all, to bootstrap, I need to run ./configure before anything
> else. Presumably, when there is a release, there will be a tarball that
> will include everything, but right now this pulls in a bunch of
> submodules via git. I can't really distribute a package that pulls
> things from git during the build phase, and will find it really
> difficult to put into the debian archive src/*/.git directories.
> Presumably this will be resolved when a release tarball will be made?

Right. Releases will be source tarballs with all of our separate git
repositories included directly.

> I'd like to decouple this from the package building process, as some of
> these are already available as independent packages in Debian, and it is
> against the Debian policy to have embedded code-copies of software that
> is available elsewhere. However, I am unsure which of these are couchdb
> specific, and which are just necessary dependencies
> The following are already in Debian, and maybe could just be
> re-used. The ones that are being pulled in via the rebar.config.script
> are directly from the master branch of these projects. Can couchdb
> declare a specific version dependency for these so that we can link them
> directly by re-using the existing libraries, instead of cloning the git
> repository? Or are there specific changes that you have done that are
> not upstream?
> folsom
> goldrush
> ibrowse
> jiffy
> mochiweb

This bit is unfortunately a similar impedance mismatch with Debian
policy as exists for Python modules and the like. Debian wants to
package them even though Erlang standard practice is to depend on the
project repository and pull it in at compile time. More on this below.

> Then there are the remaining ones. Which of the following are just
> general erlang libraries that we could work on getting into debian
> separately, and then making couchdb detect if they are installed on
> installation, and error out if they are not?
> b64url
> cassim
> couch_log
> chttpd
> couch
> couch_index
> couch_mrview
> couch_replicator
> couch_dbupdates
> couch_plugins
> couch_event
> couch_stats
> docs
> ddoc_cache
> ets_lru
> fabric
> fauxton
> global_changes
> ioq
> khash
> mem3
> oauth
> rexi
> setup
> snappy

oauth is the only dependency that's not authored by the CouchDB
project. Of the others there are a couple that *might* be useful as
libraries but I don't think anyone is using them but us. Most of them
though are specific to CouchDB and not usable without CouchDB. Erlang
is an odd beast in that its a flat namespace that still wants to group
bits of logic. Thus it either forces you to separate out work into
multiple Git repositories or muck around with manually setting
versions and so on in various places. Neither is a super awesome
solution but this was the one we currently have.

The other issue with Debian policy as you point out for the erts
directory, distributing an Erlang application contains the entire VM
and all application code (ie, from the stdlib on up). Hence when we
changed to follow the Erlang approach to packaging we broke heavily
with Debian policy by default. That's not to say we can't make things
work with Debian, it just makes things a bit more complicated.

I think the best approach would be to go and look at another Erlang
project thats already been packaged for Debian and try and see if they
have any tips on how to integrate with rebar or a similar current
Erlang build/packaging tool. We're not tied to rebar necessarily but
we will want to use one of the standard approaches (which is mostly
rebar, but seems to be picking up steam lately).

> Another issue is that I can't seem to get a build prefix to work in a
> reasonable way.
> If I pass the following options to configure:
> -p $(DESTDIR)/usr -d ../var/lib/couchdb -v ../var/lib/couchdb
> in order that things are installed properly into the debian package, and
> then I install the package, I end up with things in very strange
> locations:
> /usr/share/server/main.js
> /usr/share/server/coffee-script.js
> /usr/releases
> /usr/releases/
> /usr/releases/RELEASES
> /usr/releases/2.0.0a
> /usr/releases/2.0.0a/sys.config
> /usr/releases/2.0.0a/couchdb.boot
> /usr/releases/2.0.0a/vm.args
> /usr/releases/2.0.0a/start_clean.boot
> /usr/releases/2.0.0a/couchdb.script
> /usr/releases/2.0.0a/start_clean.rel
> /usr/releases/2.0.0a/start_clean.script
> /usr/releases/2.0.0a/couchdb.rel
> /usr/erts-6.2
> ...
> /usr/var
> /usr/var/log
> /usr/var/log/couchdb.log
> /usr/etc
> /usr/etc/local.ini
> ...
> (same result if I pass -p $(DESTDIR)/)
> I would like things to get installed in some commonly accepted
> directories:
> /etc/couchdb - config files
> /var/log/couchdb - log files
> /var/lib/couchdb - data directory
> /usr/bin/couchdb - binary
> /usr/lib/erlang/lib - dependent libraries
> /usr/lib/erlang/releases - what is being put in /usr/releases maybe?
> right now all the libraries are being put in /usr/lib directly (and I'm
> concerned about the install of /usr/lib/erts-6.2, i've already got this
> installed in /usr/lib/erlang/erts-62 from my erlang install).
> Some other minor documentation issues follow.
> The Install.UNIX says:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> Installing                                                           >
>> ----------                                                           >
>>                                                                      >
>> Once you have satisfied the dependencies you should run:             >
>>                                                                      >
>>     ./configure                                                      >
>>                                                                      >
>> This script will configure CouchDB to be installed into `/usr/local` >
>> by default.                                                          >
>>                                                                      >
>> If you wish to customize the installation, pass `--help` to this     >
>> script.                                                              >
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> The last two sentences are not true. It will be installed into
> /opt/couchdb by default, and --help doesn't work, only -h.
> The README-DEV says:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> If you intend to run the test suites:                                 >
>>                                                                       >
>>     ./configure -c                                                    >
>>                                                                       >
>> If you want to build it into different destination than `/usr/local`. >
>>                                                                       >
>>     ./configure --prefix=/<your directory path>                       >
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> both of those are wrong. The -c option currently is:
>   -c            request that couchjs is linked to cURL (default false)
> and there is no --prefix option.
> That is all for now! Thanks!
> micah

As you've run into, the ./configure is not at all a standard
./configure script. Its used almost exclusively for building an Erlang
release which results in a single self contained tarball (including
the entire Erlang VM). There was some historical half hearted attempts
at adding some familiar options but as you've seen they aren't quite
up to the task of meeting Debian's packaging requirements.

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.

Let us know if you have any other questions.


View raw message