ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Can I use metapackage to define my release list of packages?

asked 2014-12-04 03:45:50 -0600

Damien gravatar image

Hi. We have developed lots of different packages in our group. However from these packages, we want to release various "products" as individual debians.

In previous questions I discussed options to generate our own debians outside of the ROS buildfarm. At the end we chose for sake of simplicity to run

catkin_make install
and use FPM to generate a debian form the install folder. This works fine for us since we have total control on the machine where it will be deployed. And we have it automated with buildbot.

fpm -s dir -t deb

So basically now, what I need is to specify WHICH packages I want to build and install for each release. Since I ship directly the contents of /install I cannot permit catkin_to compile everything in the catkin_ws....

I don't want either to generate a release branch in my SVN in order to maintain a simple process and limit the overhead of our release management process.

So I had in mind to use a catkin metapackage defining the <run_depend> list so that it contains all and only the packages I decide to ship in my release (of course I expect catkin to manage dependencies).

The issue I have is that either

 catkin_make -DCATKIN_WHITELIST_PACKAGES=my_release_metapackage 


 catkin_make --pkg my_release_metapackage 

still compile ALL the packages in the catkin_ws... and not ONLY the ones specified in the <run_depend>...

So: 1. Are matapackages the correct way to do what I want?? If so, how should I do it? 2. Is there any other way to just compile and install a specific list of packages??


edit retag flag offensive close merge delete


Hi, I see you were able to work FPM. How did that work , did you create a debian file with all the packages of your catkin workspace? I'm trying to do exactly that but without success ..

billyDong gravatar image billyDong  ( 2018-05-24 04:27:35 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2014-12-16 13:49:24 -0600

William gravatar image

What is part of a distribution is essentially what our distribution.yaml file defines for our build farm:

We can further prune this list using the corresponding release build file:

This is all defined in the REP's 137 ( ) and 143 ( ).

Now unless you are going to setup a version of our build farm (there is on going work to make this easier, this is not done yet, see: ) you'll need to figure out what to build like you said.

One way to do these high level groupings is with metapackages. We do something like this for our "variants":

However, for your scenario I would suggest just having all of your packages in one workspace and use catkin build from python-catkin-tools (caveat is that it is not 100% completed, but should work for your use case) or catkin_make_isolated in order to pick and choose what you build and install. You can install different sets of packages into different install spaces and wrap up those install spaces with fpm.

You can look at the documentation for catkin-tools' catkin build command for more details on how to control what to build:

edit flag offensive delete link more

answered 2014-12-04 04:11:58 -0600

gvdhoorn gravatar image

updated 2014-12-16 01:36:37 -0600

Would using .rosinstall files be an option?

To separately build your 'releases', it would mean creating workspaces for each release, but those could be temporary. The .rosinstall file would group all packages that you consider to be part of the release. wstool merge URL && wstool up could then be used to easily populate the workspace. Invoking catkin_make on that workspace would only build the packages in it, nothing more. Dependency resolution would still work as normal.

.rosinstall files support specifying versions, checking out from tags (since you're using SVN) and could themselves be versioned (they're just text files). If properly named, they would also be easily recognisable.


Perhaps not a real answer to your question, but reading the new wiki page about the new buildfarm setup reminded me of the requirements you describe. You might be able to exploit the configurability of the new buildfarm setup to get something a little more automated. Especially the Build a entirely custom ROS Distro section under buildfarm - Use Cases seems to fit your use case.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2014-12-04 03:45:50 -0600

Seen: 431 times

Last updated: Dec 16 '14