ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Generate deb from dependent res package locally

asked 2018-01-18 11:34:46 -0500

tolliug gravatar image

updated 2018-01-19 02:55:00 -0500

Hi everyone,

I try to generate a deb file from a ros package A. This package depends on an other one B and I therefore added a build_depend and run_depend in the package.xml for A.

This works well with catkin but didn't succeed to run bloom. rosdep can't resolve key B. I googled this issue and see that an option could be to fork ros distro and hand tune index.yaml. This sounds to me a very complex task for just adding a dependency between package and I am wondering if it is possible to perform deb generation locally. Any help or idea about this? I read a lot of documentation but did not find any simple tutorials to achieve this issue directly.

Best regards

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2018-01-18 16:51:34 -0500

nuclearsandwich gravatar image

updated 2018-10-08 08:52:13 -0500

VictorLamoine gravatar image

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

  ubuntu: [ros-kinetic-bedlam]
  1. Add the local file to your rosdep sources. For example create /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 ... (more)

edit flag offensive delete link more



Is there an example repo that shows off the whole process? It could be a hello world publisher ros node in a package that gets turned into a deb with step-by-step instructions, and then someone could relatively easily substitute their own packages and turn them into debs.

lucasw gravatar image lucasw  ( 2018-03-08 10:07:46 -0500 )edit

I want to share an interesting thing. When I use git-bloom-release to release a kinetic track, and the upstream includes two packages A and B, and B depends on A, (rosdep can't resolve key A), but it doesn't fail... It succeed in transforming the A to ros-kinetic-A when git-bloom-generate for B...

zcm gravatar image zcm  ( 2018-03-08 21:06:50 -0500 )edit

Append: git-bloom-release --version shows 0.6.2

zcm gravatar image zcm  ( 2018-03-08 21:08:14 -0500 )edit

@zcm the scenario you describe includes a circular dependency. Which will cause problems down the road when performing clean builds even if bloom succeeds. Are A and B two packages in the same repository? Or have you pre-populated your distribution.yaml file with the package information?

nuclearsandwich gravatar image nuclearsandwich  ( 2018-03-19 12:23:49 -0500 )edit

@nuclearsandwich , I checked again my project and distribution.yaml file: A and B are in the same repo, I haven't pre-populated my distribution.yaml file.

zcm gravatar image zcm  ( 2018-03-20 06:38:15 -0500 )edit

I don't know why... Maybe I should find a clean machine to test again when I have some time. :-)

zcm gravatar image zcm  ( 2018-03-20 06:48:24 -0500 )edit

I suspect that if your packages have build time dependencies on each other, they'll fail to build on a clean machine unless your build tool has a cycle-breaking heuristic and the dependency is unneeded. It would be a good idea to break the cycle through refactoring.

nuclearsandwich gravatar image nuclearsandwich  ( 2018-03-20 07:13:18 -0500 )edit

Hello, I've done this process to solve the dependency but later when I try to build a .deb file it fails:

$ fakeroot  debian/rules binary

You can see the bash in the link: fakeroot bash

billyDong gravatar image billyDong  ( 2018-04-12 04:29:09 -0500 )edit

Question Tools



Asked: 2018-01-18 11:34:46 -0500

Seen: 2,782 times

Last updated: Oct 08 '18