Closed nuclearsandwich closed 6 years ago
Why should there be added to upstream if they have to be modified in the release process to suggests anyway?
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.
The build dependencies will stay build dependencies.
:+1:
The build_export dependencies below will be moved into suggests to keep them out of the runtime dependencies.
Should those be removed from the manifest then (if they are are covered by a group dependency)?
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 group_depend
is treated like an unspecified depend
they're covered by the group.
@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.
Connects to ros2/rmw_implementation#41
This change is motivated by the discussion in https://github.com/ros2/rmw_implementation/pull/41#discussion_r197289719
The build_export dependencies on the vendor typesupport packages will be moved into Suggests in the debian/control templates after bloom generates them.