| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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?
tldr;
catkin_ws/src/my_project/debian/udev -> /lib/udev/rules.d/60-ros-${ROS_DISTRO}-my-project.rulescatkin_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-projectExplanation 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:
Asked: 2019-08-25 12:31:11 -0500
Seen: 302 times
Last updated: Aug 28 '19
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
I believe #q133966 discusses this. #q239969 would be another Q&A.
If those answer your question, please close this one as a duplicate.
@gvdhoorn, almost any file I could place under a
debiandirectory 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.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).
well, yes. But afaik there is only support for this sort of thing in the
rosdebiangenerator.Perhaps @William can provide some additional insight.
@gvdhoorn, could you explain how one might install, say, a udev rule from a package-specific
debiandirectory? Assuming every $ROS_DISTRO needs the same file content, what would you name it?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).
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.
@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 thefoobar.servicefile.Also, I note that vanilla
dh_installudevdoesn't support the kind of semantics you reference; i.e., it expects files of the form${package}.udevand notudevas shown in https://github.com/ros-drivers/pointg... . What is this mechanism and where is it documented?I learned something today.
--- http://man7.org/linux/man-pages/man7/... , "debhelper config files"
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.