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

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

or

 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??

Thanks

edit retag 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 ..

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

Sort by » oldest newest most voted

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

https://github.com/ros/rosdistro/blob...

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

https://github.com/ros/rosdistro/blob...

This is all defined in the REP's 137 ( http://www.ros.org/reps/rep-0137.html ) and 143 ( http://www.ros.org/reps/rep-0143.html ).

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: http://wiki.ros.org/buildfarm#Use_Cases ) 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":

https://github.com/ros/metapackages

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:

more

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.

Edit:

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.

more