Prepare dependencies for bouncy release. #27
Conversation
|
Why should there be added to upstream if they have to be modified in the release process to suggests anyway? |
The build dependencies will stay build dependencies. The build_export dependencies below will be moved into suggests to keep them out of the runtime dependencies. If there is a preference to keep release package.xmls/dependencies as closely in sync with upstream as possible then this PR does that. If instead the preference is to only contribute changes upstream when it avoids manual work at release time then this PR can be closed and I'll not open future ones unless I can avoid release patching by doing so. |
👍
Should those be removed from the manifest then (if they are are covered by a group dependency)? |
I don't believe there's anything stopping us from removing it. We lose some precision on the intent but as long as |
Updated verbiage pulled from ros2/rmw_implementation#41
|
@mikaelarguedas @dirk-thomas the existing approval notwithstanding the question of whether or not to remove the build export dependencies from the upstream package.xml is still open. |
|
Since I suggested the removal in the first place I am in favor of doing so. Since it isn't needed in from-source builds and the Debian packages don't want a "hard" runtime dependency either. |
These packages are members of the groups rosidl_typesupport_c_packages and rosidl_typesupport_cpp_packages respectively and do not need to be specified as build_export depends explicitly.
Connects to ros2/rmw_implementation#41
This change is motivated by the discussion in ros2/rmw_implementation#41 (comment)
The build_export dependencies on the vendor typesupport packages will be moved into Suggests in the debian/control templates after bloom generates them.