Install completion, gz tool scripts lib package #16
Conversation
Forward port of gazebo-release/gz-transport8-release#3. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
|
testing this branch: |
|
this needs more work, probably a backport of gazebo-release/gz-transport11-release#4 as well |
| @@ -1 +1,4 @@ | |||
| usr/lib/*/lib*-transport[0-9][0-9].so.* | |||
| usr/lib/ruby/*/cmdtransport[0-9][0-9].rb | |||
| usr/share/*/transport[0-9][0-9].yaml | |||
There was a problem hiding this comment.
I tested locally by adding the usr/libexec path like so:
| usr/share/*/transport[0-9][0-9].yaml | |
| usr/share/*/transport[0-9][0-9].yaml | |
| usr/libexec/gz/transport[0-9][0-9]/* |
and it seems to work. In the gazebo-release/gz-transport11-release#4, we create a new package called ignition-transport11-cli, add it as a dependency of libignition-transport11-dev. However, we now want these binaries to be part of the non-dev package, but we can't add a dependency of gz-transport12-cli onto libgz-transport12 since that will create a dependency cycle. I propose we just add these binaries to libgz-transport12 and drop the cli package. @j-rivero thoughts?
There was a problem hiding this comment.
I believe we need the CLI to be in a non-lib package, because that's now installing a binary, even though it is a libexec one, and not bin
There was a problem hiding this comment.
In the gazebo-release/gz-transport11-release#4, we create a new package called
ignition-transport11-cli, add it as a dependency oflibignition-transport11-dev. However, we now want these binaries to be part of the non-dev package,
Let's stop here. Let me summarize the situation of the software pieces: we have a software composed by: main lib (libgz-transport12-dev), developer headers + helpers (libgz-transport12-dev and a cli program (gz-transport12-cli). The (hard -> Depends: in Debian) dependencies should be strict in the way that the package is not going to work without the dep. So the cli program probably depends on the lib but the lib should not depend on cli package since it does not need it. We can use other sotf dependencies (Suggest, Recommends) to handle the behavior we want. So my proposal would be:
- Keep the cli package (useful), make it
Dependson the main lib - If we want people to install the CLI together with the lib by default, make the cli a
Suggestof the main lib. - The development package should depend on the lib + cli or we can move the cli to be also a
Suggest(final behavior is the same, package manager install it together, latter seems to me like a more correct approach).
I believe we need the CLI to be in a non-lib package, because that's now installing a binary, even though it is a
libexecone, and notbin
If we are strict with the Debian policy about shared libraries, then yes, they should into their own individual package so you can have two library packages from different versions installed together.
There was a problem hiding this comment.
Sounds good. @scpeters I can make the changes, if that's okay.
There was a problem hiding this comment.
please do so, thanks for taking this over
Signed-off-by: Addisu Z. Taddese <addisu@openrobotics.org>
|
New build with 1b4f4f4 |
| @@ -1 +1,3 @@ | |||
| usr/lib/*/lib*-transport[0-9][0-9]-log.so.* | |||
| usr/lib/ruby/*/cmdlog[0-9][0-9].rb | |||
| usr/share/*/transportlog[0-9][0-9].yaml | |||
There was a problem hiding this comment.
Should we put these in the CLI package instead? Or do we need a log-cli package?
There was a problem hiding this comment.
I'm going to leave this one like this and merge the PR to fix the libexec issue
Signed-off-by: Louise Poubel <louise@openrobotics.org>
Forward port of gazebo-release/gz-transport8-release#3.
Intending to fix unstable debbuilds: