Revision history [back]

Bloom is designed primarily to generate debian packages to be used in the context of a release into a ROS distro. It's possible to use it for creating "standalone" debian packages but it requires some deviation from the expected path and a fair bit of legwork.

One expedient path to allowing bloom to run would be:

1. Run bloom on package B to make sure its dependencies are all resolvable.

2. Create a rosdep.yaml file on your local machine and populate it with the key name and package name pair for package B. For example if the package name of package B is bedlam and the debian package name is ros-kinetic-bedlam, create a file with the contents

bedlam:
  ubuntu: [ros-kinetic-bedlam]

1. Add the local file to your rosdep sources. For example create /etc/ros/rosdep/source.list.d/50-my-packages.list with the contents

yaml file:///path/to/your/rosdep.yaml

1. Run bloom on package A. It should pick up the local rosdep data and resolve the dependency to the package name specified.

This is still pretty involved and unless you deploy the rosdep changes to any target machines of the debian package, rosdep may incorrectly report that your package A's dependencies are not satisfied. It also doesn't help other collaborators you have when they need to run bloom to create a new release. If this is something you're going to be doing often, or in an automated fashion, having a forked rosdistro set up might be better long term.

Bloom is designed primarily to generate debian packages to be used in the context of a release into a ROS distro. It's possible to use it for creating "standalone" debian packages but it requires some deviation from the expected path and a fair bit of legwork.

One expedient path to allowing bloom to run would be:

1. Run bloom on package B to make sure its dependencies are all resolvable.

2. Create a rosdep.yaml file on your local machine and populate it with the key name and package name pair for package B. For example if the package name of package B is bedlam and the debian package name is ros-kinetic-bedlam, create a file with the contents

bedlam:
  ubuntu: [ros-kinetic-bedlam]

1. Add the local file to your rosdep sources. For example create /etc/ros/rosdep/source.list.d/50-my-packages.list with the contents

yaml file:///path/to/your/rosdep.yaml

1. Run bloom on package A. It should pick up the local rosdep data and resolve the dependency to the package name specified.

This is still pretty involved and unless you deploy the rosdep changes to any target machines of the debian package, rosdep may incorrectly report that your package A's dependencies are not satisfied. It also doesn't help other collaborators you have when they need to run bloom to create a new release. If this is something you're going to be doing often, or in an automated fashion, having a forked rosdistro set up might be better long term.

Bloom is designed primarily to generate debian packages to be used in the context of a release into a ROS distro. It's possible to use it for creating "standalone" debian packages but it requires some deviation from the expected path and a fair bit of legwork.

One expedient path to allowing bloom to run would be:

1. Run bloom on package B to make sure its dependencies are all resolvable.

2. Create a rosdep.yaml file on your local machine and populate it with the key name and package name pair for package B. For example if the package name of package B is bedlam and the debian package name is ros-kinetic-bedlam, create a file with the contents

bedlam:
  ubuntu: [ros-kinetic-bedlam]

1. Add the local file to your rosdep sources. For example create /etc/ros/rosdep/source.list.d/50-my-packages.list/etc/ros/rosdep/sources.list.d/50-my-packages.list with the contents

yaml file:///path/to/your/rosdep.yaml

1. Run bloom on package A. It should pick up the local rosdep data and resolve the dependency to the package name specified.

This is still pretty involved and unless you deploy the rosdep changes to any target machines of the debian package, rosdep may incorrectly report that your package A's dependencies are not satisfied. It also doesn't help other collaborators you have when they need to run bloom to create a new release. If this is something you're going to be doing often, or in an automated fashion, having a forked rosdistro set up might be better long term.

I'd like to address a specific paragraph of a duplicate question.

I think we should be able to create the release repo before add rosdep key 'A' to the rosdistro. We only need to push changes to rosdistro file after release repo created. Because package A is just in our current catkin workspace ?

Bloom doesn't inspect your catkin workspace and works at the repository resolution only. And this is a good thing. Your catkin workspace may have many packages in various overlays or underlays that aren't part of the rosdistro or rosdep metadata and if bloom were to read those packages it would make reasoning about your release very difficult.

Instead, when running bloom, you should bloom the dependency packages 'B' or 'bedlam' in the above example before blooming the dependent 'A' package. Since ROS packages cannot be circularly dependent, there should always a topological order to bloom packages in.

There is one case where this process becomes more difficult and manual: If you have two repositories, one and two. Repository one contains packages 'A' and 'C', repository two contains package 'B'. But A depends on B and B depends on C. Then you have to fudge B into the rosdistro file before you can run bloom on repository one (because A depends on B, but B needs C to be in the rosdistro first). This is a complex and confusing setup in general and should probably be avoided either by keeping all packages three in one repository or giving each their own repository.