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-...
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
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.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
rosdebian
generator.Perhaps @William can provide some additional insight.
@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?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-buildpackage
d, conspicuously lacks any systemd unit, despite the presence of thefoobar.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 notudev
as 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.