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/MakefileSo, 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.