Tuesday, November 29, 2011

conary dir


Some conary recipe methods (including addArchive, Make, etc.) accept a "dir" parameter. It allows you to specify a custom directory within which to execute the action. What's confusing is that, its behavior is not so consistent (when dir is a relative directory).

addArchive() by default works inside the "builddir", usually ~/conary/builds/foobar/ (that is the buildPath; check your buildPath with `conary config | grep buildPath`). So an explicit "dir" argument for addArchive is relative to the builddir.

For Make(), MakeInstall(), etc., they work inside the "maindir", usually ~/conary/builds/foobar/foobar-1.0/. So "dir" for them is relative to maindir.

Here is an example.

Some time ago I needed to add an additional tarball to the conary package. This is what it takes.
r.addArchive('https://some/url/conary-bash-completion-0.2.tar.bz2', dir='%(maindir)s')
r.Make(dir='conary-bash-completion-0.2')
r.MakeInstall(dir='conary-bash-completion-0.2')
The tarball has such a structure,
$ tar tf conary-bash-completion-0.2.tar.bz2
conary-bash-completion-0.2/
conary-bash-completion-0.2/generate.py
conary-bash-completion-0.2/README
conary-bash-completion-0.2/Makefile
So, the addArchive() call will extract the tarball at the maindir, ~/conary/builds/conary/conary-2.3/. The files will be available under ~/conary/builds/conary/conary-2.3/conary-bash-completion-0.2. And Make and MakeInstall will work inside that directory.