ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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.
2 | No.2 Revision |
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 .
3 | No.3 Revision |
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.
4 | No.4 Revision |
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.
5 | No.5 Revision |
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 association to an implicit package name is useful, say, when you don't know the debhelper
to install things 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 be expanded via @(VariableName)
replaced with the value of VariableName
empy
. This facility is heavily used on the For details, see the contents of https://github.com/ros-infrastructure/bloom/tree/master/bloom/generators/debian/templates .rosdebian
and debian
generator targets.
In the case where you have a debian/foo
and a debian/foo.em
, the expansion of the latter overwrites the former.
6 | No.6 Revision |
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
7 | No.7 Revision |
tldr;
dh_installudev
:
/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
8 | No.8 Revision |
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 how it goes looking for files: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
9 | No.9 Revision |
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