ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

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.7.html, "Debhelper Config Files" section

This is the trickery that must be used tell debhelper to install things when you don't know the package name; i.e., foo in the quoted example. The particular kinds of files that are supported include but are not limited to the following:

  • debian/udev via dh_installudev
  • debian/service via dh_installinit
  • debian/logrotate via dh_installlogrotate

I'm sure there are many others. I'll add them to this answer as I am able to confirm their proper function under bloom conditions.

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.7.html, "Debhelper Config Files" section

This is the trickery that must be used tell debhelper to install things when you don't know the package name; i.e., foo in the quoted example. The particular kinds of files that are supported include but are not limited to the following:

  • debian/udev via dh_installudev
  • debian/service via dh_installinit
  • debian/logrotate via dh_installlogrotate

I'm sure there are many others. I'll add them to this answer as I am able to confirm their proper function under bloom conditions.

Also, bloom does template files; i.e., files bearing the TEMPLATE_EXTENSION (defined in https://github.com/ros-infrastructure/bloom/blob/master/bloom/generators/debian/generator.py, defaulting to .em) will have every instance of @(VariableName) replaced with the value of VariableName. This facility is heavily used on the rosdebian and debian generator targets. For details, see the contents of https://github.com/ros-infrastructure/bloom/tree/master/bloom/generators/debian/templates .

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.7.html, "Debhelper Config Files" section

This is the trickery that must be used tell debhelper to install things when you don't know the package name; i.e., foo in the quoted example. The particular kinds of files that are supported include but are not limited to the following:

  • debian/udev via dh_installudev
  • debian/service via dh_installinit
  • debian/logrotate via dh_installlogrotate

I'm sure there are many others. I'll add them to this answer as I am able to confirm their proper function under bloom conditions.

Also, bloom does template files; i.e., files bearing the TEMPLATE_EXTENSION (defined in https://github.com/ros-infrastructure/bloom/blob/master/bloom/generators/debian/generator.py, defaulting to .em) will have every instance of @(VariableName) replaced with the value of VariableName. This facility is heavily used on the rosdebian and debian generator targets. For details, see the contents of https://github.com/ros-infrastructure/bloom/tree/master/bloom/generators/debian/templates .

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

Caveat: the following solution only works for Debian and Debian-based distributions.

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.7.html, "Debhelper Config Files" section

This is the trickery that must be used tell debhelper to install things when you don't know the package name; i.e., foo in the quoted example. The particular kinds of files that are supported include but are not limited to the following:

  • debian/udev via dh_installudev
  • debian/service via dh_installinit
  • debian/logrotate via dh_installlogrotate

I'm sure there are many others. I'll add them to this answer as I am able to confirm their proper function under bloom conditions.

Also, bloom does template files; i.e., files bearing the TEMPLATE_EXTENSION (defined in https://github.com/ros-infrastructure/bloom/blob/master/bloom/generators/debian/generator.py, defaulting to .em) will have every instance of @(VariableName) replaced with the value of VariableName. This facility is heavily used on the rosdebian and debian generator targets. For details, see the contents of https://github.com/ros-infrastructure/bloom/tree/master/bloom/generators/debian/templates .

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

Caveat: the following solution tldr;

  • dh_installudev:
    • catkin_ws/src/my_project/debian/udev -> /lib/udev/rules.d/60-ros-${ROS_DISTRO}-my-project.rules
  • dh_installinit:
    • catkin_ws/src/my_project/debian/service -> /lib/systemd/system/ros-${ROS_DISTRO}-my-project.service
  • dh_installlogrotate:
    • 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.distributions --- specifically, bloom allows this for the rosdebian and debian generator targets.

This works because of a certain quirk in the behavior of debhelper:

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.7.html, "Debhelper Config Files" section

This is the trickery that must be used tell debhelper to install things association to an implicit package name is useful, say, when you don't know the package name; 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., foo in the quoted example. The particular kinds of files that are supported include but are not limited to the following:

  • debian/udev via dh_installudev
  • debian/service via dh_installinit
  • debian/logrotate via dh_installlogrotate

I'm sure there are many others. I'll add them to this answer as I am able to confirm their proper function under bloom conditions.

Also, bloom does the developer doesn't know the name of the package until _after_ the package is bloomed.

Better yet, one can use template files; i.e., files files. Files within the catkin project debian directory bearing the TEMPLATE_EXTENSION (defined in https://github.com/ros-infrastructure/bloom/blob/master/bloom/generators/debian/generator.py, defaulting to .em) will have every instance of @(VariableName) replaced with the value of VariableNamebe expanded via empy. This facility is heavily used on the rosdebian and debian generator targets. For details, see the contents of https://github.com/ros-infrastructure/bloom/tree/master/bloom/generators/debian/templates .

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

tldr;

  • dh_installudev:
    • catkin_ws/src/my_project/debian/udev -> /lib/udev/rules.d/60-ros-${ROS_DISTRO}-my-project.rules
  • dh_installinit:
    • catkin_ws/src/my_project/debian/service -> /lib/systemd/system/ros-${ROS_DISTRO}-my-project.service
  • dh_installlogrotate:
    • 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 of a certain quirk in the behavior of debhelper:

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.7.html, "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/bloom/blob/master/bloom/generators/debian/generator.py, defaulting to .em) will be expanded via empy. For details, see the contents of https://github.com/ros-infrastructure/bloom/tree/master/bloom/generators/debian/templates .

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-bloom-debhelper

tldr;

  • dh_installudev:
      catkin_ws/src/my_project/debian/udev -> /lib/udev/rules.d/60-ros-${ROS_DISTRO}-my-project.rules
    • catkin_ws/src/my_project/debian/udevcatkin_ws/src/my_project/debian/service -> /lib/udev/rules.d/60-ros-${ROS_DISTRO}-my-project.rules/lib/systemd/system/ros-${ROS_DISTRO}-my-project.service
  • dh_installinit:
    • catkin_ws/src/my_project/debian/servicecatkin_ws/src/my_project/debian/logrotate -> /lib/systemd/system/ros-${ROS_DISTRO}-my-project.service
  • dh_installlogrotate:
    • 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 of a certain quirk in the behavior of debhelper:

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.7.html, "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/bloom/blob/master/bloom/generators/debian/generator.py, defaulting to .em) will be expanded via empy. For details, see the contents of https://github.com/ros-infrastructure/bloom/tree/master/bloom/generators/debian/templates .

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-bloom-debhelper

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 of a certain quirk bloom uses debhelper and debhelper has some nice fallback behavior in the behavior of debhelper: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.7.html, "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/bloom/blob/master/bloom/generators/debian/generator.py, defaulting to .em) will be expanded via empy. For details, see the contents of https://github.com/ros-infrastructure/bloom/tree/master/bloom/generators/debian/templates .

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-bloom-debhelper

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.7.html, "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/bloom/blob/master/bloom/generators/debian/generator.py, defaulting to .em) will be expanded via empy. For details, see the contents of https://github.com/ros-infrastructure/bloom/tree/master/bloom/generators/debian/templates .

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-bloom-debhelper