Revision history [back]

Multi-Arch control fields aren't included in the bloom packaging templates for debian so there's no explicit support for multiarch per the Debian and Ubuntu documentation. Nor are different architectures of ROS packages co-installable.

Multiarch support is not a planned feature on the ROS 2 Roadmap. A few packages that use a multiarch installation from upstream are packaged in ardent to use newer versions than are available on xenial. Those packages required changes to packaging configuration in their reverse-dependencies in order to support GNUInstallDirs. These changes are still made on a per-package basis and there aren't current plans to try and generically add them to bloom's templates.

Is multiarch supported and would it depend on whether GNUInstallDirs is loaded in the respective CMakeLists.txt, or are there still some blocking issues that need to be resolved?

I'm not confident on all the necessary details but I'm pretty sure that for a start: a ROS package attempting to use GNUInstallDirs would need to also register environment hooks to make sure the multiarch dir is on the library path.

One blocking issue I can think of off the top of my head, which to my knowledge are not even generally solved upstream[1], are the handling of headers and dev dependencies in a multiarch setting. Since ROS packages don't separate dev dependencies into separate packages, this pretty much blocks multiarch support unless we either resolve the co-installability satisfactorily or separate dev packages out.

I believe the pull requests linked above are about supporting upstream dependencies with multiarch configuration (console-bridge and urdfdom)

Multi-Arch control fields aren't included in the bloom packaging templates for debian so there's no explicit support for multiarch per the Debian and Ubuntu documentation. Nor are different architectures of ROS packages co-installable.

Multiarch support is not a planned feature on the ROS 2 Roadmap. A few packages that use a multiarch installation from upstream are packaged in ardent to use newer versions than are available on xenial. Those packages required changes to packaging configuration in their reverse-dependencies in order to support GNUInstallDirs. These changes are still made on a per-package basis and there aren't current plans to try and generically add them to bloom's templates.

Is multiarch supported and would it depend on whether GNUInstallDirs is loaded in the respective CMakeLists.txt, or are there still some blocking issues that need to be resolved?

I'm not confident on all the necessary details but I'm pretty sure that for a start: a ROS package attempting to use GNUInstallDirs would need to also register environment hooks to make sure the multiarch dir is on the library path.

One blocking issue I can think of off the top of my head, which to my knowledge are not even generally solved upstream[1], are the handling of headers and dev dependencies in a multiarch setting. Since ROS packages don't separate dev dependencies into separate packages, this pretty much blocks multiarch support unless we either resolve the co-installability satisfactorily or separate dev packages out.

I believe the pull requests linked above are about supporting upstream dependencies with multiarch configuration (console-bridge and urdfdom)

Multi-Arch control fields aren't included in the bloom packaging templates for debian so there's no explicit support for multiarch per the Debian and Ubuntu documentation. Nor are different architectures of ROS packages co-installable.

Multiarch support is not a planned feature on the ROS 2 Roadmap. A few packages that use a multiarch installation from upstream are packaged in ardent to use newer versions than are available on xenial. Those packages required changes to packaging configuration in their reverse-dependencies in order to support GNUInstallDirs. These changes are still made on a per-package basis and there aren't current plans to try and generically add them to bloom's templates.

Is multiarch supported and would it depend on whether GNUInstallDirs is loaded in the respective CMakeLists.txt, or are there still some blocking issues that need to be resolved?

I'm not confident on all the necessary details but I'm pretty sure that for a start: a ROS package attempting to use GNUInstallDirs would need to also register environment hooks to make sure the multiarch dir is on the library path.

One blocking issue I can think of off the top of my head, which to my knowledge are not even generally solved upstream[1], upstream₁, are the handling of headers and dev dependencies in a multiarch setting. Since ROS packages don't separate dev dependencies into separate packages, this pretty much blocks multiarch support unless we either resolve the co-installability satisfactorily or separate dev packages out.

I believe the pull requests linked above are about supporting upstream dependencies with multiarch configuration (console-bridge and urdfdom) and not adding multiarch to ROS packages but I could be wrong about the scope.

Edit: Finished a sentence in the final paragraph.

Multi-Arch control fields aren't included in the bloom packaging templates for debian so there's no explicit support for multiarch per the Debian and Ubuntu documentation. Nor are different architectures of ROS packages co-installable.

Multiarch support is not a planned feature on the ROS 2 Roadmap. A few packages that use a multiarch installation from upstream are packaged in ardent to use newer versions than are available on xenial. Those packages required changes to packaging configuration in their reverse-dependencies in order to support GNUInstallDirs. These changes are still made on a per-package basis and there aren't current plans to try and generically add them to bloom's templates.

Is multiarch supported and would it depend on whether GNUInstallDirs is loaded in the respective CMakeLists.txt, or are there still some blocking issues that need to be resolved?

I'm not confident on all the necessary details but I'm pretty sure that for a start: a ROS package attempting to use GNUInstallDirs would need to also register environment hooks to make sure the multiarch dir is on the library path.

One blocking issue I can think of off the top of my head, which to my knowledge are not even generally solved upstream1, are the handling of headers and dev dependencies in a multiarch setting. Since ROS packages don't separate dev dependencies into separate packages, this pretty much blocks multiarch support unless we either resolve the co-installability satisfactorily or separate dev packages out.

I believe the pull requests linked above are about supporting upstream dependencies with multiarch configuration (console-bridge and urdfdom) and not adding multiarch to ROS packages but I could be wrong about the scope.

Edit: Finished a sentence in the final paragraph.

Edit2: Formatting to reveal link.