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:
Run bloom on package B to make sure its dependencies are all resolvable.
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]
- 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
- 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.
Originally posted by nuclearsandwich with karma: 906 on 2018-01-18
This answer was ACCEPTED on the original site
Post score: 4
Original comments
Comment by lucasw on 2018-03-08:
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.
Comment by zcm on 2018-03-08:
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...
Comment by zcm on 2018-03-08:
Append: git-bloom-release --version shows 0.6.2
Comment by nuclearsandwich on 2018-03-19:
@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?
Comment by zcm on 2018-03-20:
@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.
Comment by zcm on 2018-03-20:
I don't know why... Maybe I should find a clean machine to test again when I have some time. :-)
Comment by nuclearsandwich on 2018-03-20:
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.
Comment by billyDong on 2018-04-12:
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
Comment by billyDong on 2018-04-12:
If you could help me here:
288410
Comment by zcm on 2018-04-12:
@billyDong , I saw the log of fakeroot, it seems that cmake can't find 'robis_math_utilities' , maybe you need to install this package.
Comment by billyDong on 2018-04-13:
@zcm, As I explaneid here 288410, That library is in a package I've previously installed in opt/ros/kinetic through the same process: bloom-generate then fakeroot, then dpkg -i. It is also in catkin
Comment by billyDong on 2018-06-08:
@nuclearsandwich @zcm could you see this please : l293599
I was able to build and install the packages, but the nodes are not generated..
Comment by codecover on 2021-02-25:
@nuclearsandwich @zcm is it the same procedure if my private dependency is pure cmake package not the ros package?
