Ask Your Question
3

Is it possible to release variants of a package with bloom (i.e. different CMake arguments)?

asked 2013-08-28 06:17:01 -0500

jbohren gravatar image

updated 2013-08-28 06:21:45 -0500

Is it possible to release variants of a package with bloom? The difference between these variants would simply be the use of different CMake configuration at build time, and then they would have different debian package names to distinguish them.

It's possible to add custom CMake commands to a bloom build, but can we make two packages which are considered to conflict with each-other, but provide some of the same libraries?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
3

answered 2013-08-28 07:25:45 -0500

William gravatar image

updated 2013-08-28 07:50:48 -0500

Not if they have the same package name. Currently you cannot build multiple debs with different configurations for a single package.

What is the use case specifically, it might be easier for me to suggest an alternative solution using bloom or something else.

EDIT

Our pipeline works best when packages do not required configuration, this may not be optimal, but it keeps our infrastructure simple. For better or worse that is the way it is. If you want multiple options to be available side by side, then you'll need to do what I have come to call configuration by packages. This is where you change the behavior of a package based on the other packages available around it.

This is done with message generation, if genlisp is available all message packages will build for lisp, otherwise it will not. This is where a package is affected by others in the workspace.

The other method, and the one I recommend, is where you have a 'source' package which exports the source code and/or a CMake project, and then you have 'configuration' packages which depend on this 'source' package and any other, normally optional, dependencies. The 'configuration' package can then build (and install and distribute) the contents of the 'source' package with what ever configurations and dependencies it wants.

Once you get to the distribution step, you would need to modify your controls file template to add a conflicts rule, or properly namespace the libraries and headers installed by each 'configuration' package.

This isn't ideal, but its the best solution I can come up with in the current infrastructure. It might be worth investigating how to do this at the packaging stage (with bloom), but I don't have the cycles for that right now, though I would work with you to design and integrate a solution if you're so motivated.

edit flag offensive delete link more

Comments

Specifically, this is for Orocos, which can be built with optional CORBA inter-process communication support, and this CORBA support can be implemented wither with the OmniOrb library or the TAO library. So really there would be three variants: orocos (no CORBA), orocos-omniorb, and orocos-tao.

jbohren gravatar image jbohren  ( 2013-08-28 07:30:30 -0500 )edit

Post-UPDATE: Alright, then we can put this on the side for now, and just keep automatically building the OmnOrb-based CORBA support for Orocos. Thanks!

jbohren gravatar image jbohren  ( 2013-08-28 07:55:36 -0500 )edit

Your Answer

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

Add Answer

Question Tools

2 followers

Stats

Asked: 2013-08-28 06:17:01 -0500

Seen: 167 times

Last updated: Aug 28 '13