# How to bloom with init system integration?

As a package maintainer for things built with catkin and released with bloom, I require the capability to install service "units" with which an init system (systemd, upstart, rc, etc.) may manage my installed programs as daemons. How do I get catkin and/or bloom to install these service units?

edit retag close merge delete

I believe #q133966 discusses this. #q239969 would be another Q&A.

( 2019-08-25 13:27:29 -0500 )edit

@gvdhoorn, almost any file I could place under a debian directory within the package would have to be named for the Debian package to which it contributes --- which is not known until _after_ the bloom. Note also, that the techniques you link do not address non-Debian package formats.

( 2019-08-26 11:58:29 -0500 )edit

which is not known until _after_ the bloom

I'm not sure I completely follow you here, but that is not true: the ROS-pkg-name-to-debian-name conversion is known a priori, so you can anticipate the value used (there is a Q&A here on ROS Answers that discusses it. Can't find it right now though).

And it's even possible to use template files and/or use pre- and postinstall hooks (#q191779).

Note also, that the techniques you link do not address non-Debian package formats.

well, yes. But afaik there is only support for this sort of thing in the rosdebian generator.

Perhaps @William can provide some additional insight.

( 2019-08-26 12:10:40 -0500 )edit

@gvdhoorn, could you explain how one might install, say, a udev rule from a package-specific debian directory? Assuming every $ROS_DISTRO needs the same file content, what would you name it? ( 2019-08-26 12:14:46 -0500 )edit I have a feeling we're not discussing the same thing(s). Please provide a concrete MWE that shows what you want to achieve (ie: some example file & directory structure that should work, but you feel doesn't, given the limitations of Bloom). how one might install, say, a udev rule from a package-specific debian directory One of the examples linked to from #q133966 appears to do exactly that (here). I'm not sure I grok the "package-specific debian directory" part of your question. ( 2019-08-26 14:03:22 -0500 )edit @gvdhoorn, here you go: https://github.com/realtime-neil/ros-... Note that the bloomed result, when dpkg-buildpackaged, conspicuously lacks any systemd unit, despite the presence of the foobar.service file. Also, I note that vanilla dh_installudev doesn't support the kind of semantics you reference; i.e., it expects files of the form ${package}.udev and not udevas shown in https://github.com/ros-drivers/pointg... . What is this mechanism and where is it documented?

( 2019-08-26 15:20:15 -0500 )edit

I learned something today.

Note for the first (or only) binary package listed in debian/control, debhelper will use debian/foo when there's no debian/package.foo file. However, it is often a good idea to keep the package. prefix as it is more explicit. The primary exception to this are files that debhelper by default installs in every binary package when it does not have a package prefix (such as debian/copyright or debian/changelog).

--- http://man7.org/linux/man-pages/man7/... , "debhelper config files"

( 2019-08-27 12:34:15 -0500 )edit

I am not completely sure that we want to recommend the installation of system-wide unit or init scripts via existing package managers since the units could collide with units from upstream or from other rosdistros on the same host. It would make the most sense to me to provide example unit or init files in share/$pkgname/examples which could be copied or symlinked into a location by a system administrator or configuration management utility. ( 2019-08-27 13:09:53 -0500 )edit ## 1 Answer Sort by » oldest newest most voted tldr; • catkin_ws/src/my_project/debian/udev -> /lib/udev/rules.d/60-ros-${ROS_DISTRO}-my-project.rules
• catkin_ws/src/my_project/debian/service -> /lib/systemd/system/ros-${ROS_DISTRO}-my-project.service • catkin_ws/src/my_project/debian/logrotate -> /etc/logrotate.d/ros-${ROS_DISTRO}-my-project

Explanation follows...

First the caveats: this trick only works for Debian and Debian-based distributions --- specifically, bloom allows this for the rosdebian and debian generator targets.

This works because bloom uses debhelper and debhelper has some nice fallback behavior in how it goes looking for files:

Note for the first (or only) binary package listed in debian/control, debhelper will use debian/foo when there's no debian/package.foo file. However, it is often a good idea to keep the package. prefix as it is more explicit. The primary exception to this are files that debhelper by default installs in every binary package when it does not have a package prefix (such as debian/copyright or debian/changelog).

-- http://man7.org/linux/man-pages/man7/..., "Debhelper Config Files" section

This association to an implicit package name is useful, say, when you don't know the name of the package for which you want to install artifacts. This is exactly the case for ROS packages targeting a Debian-like OS; i.e., the developer doesn't know the name of the package until _after_ the package is bloomed.

Better yet, one can use template files. Files within the catkin project debian directory bearing the TEMPLATE_EXTENSION(defined in https://github.com/ros-infrastructure..., defaulting to .em) will be expanded via empy. For details, see the contents of https://github.com/ros-infrastructure... .

In the case where you have a debian/foo and a debian/foo.em, the expansion of the latter overwrites the former.

Here's a working example that demonstrates the aforementioned techniques:

https://github.com/realtime-neil/ros-...

more