Binary .deb Installation of gz-tools modules provided by other gz packages

[j-rivero]

The modules supported by the gz (previosly ign) tool (such as gui, fuel, service, topic, sdf, ...) are provided by different binary packages, typically by the -dev packages. Completely separated from this submodules we also have standalone binaries (built using cli11) that can run on their own providing some interaction aside from gz.

As part of #529 I think that we have been moving some of the gz submodules out from the library packages -dev into the -cli- packages (which was proposed to host the standalone cli11 binaries). These changes also had the side effect of pulling some of them out of the default installation when someone install the library or the -dev package or the gz-garden metapackage, see gazebosim/garden-tutorial-party#1978 (comment).

So I think that we need to resolve two different somehow linked problems:

• What binary package should host the .yaml and .rb files that are part of gz submodules? Note that lib package should just contain the shared library, we don't want them in the -dev package and the -cli- package is most of the times not installed by default. In Debian the arch-independent files are typically using a -common package (see gazebo-common).
• What kind of default behaviour we want to give to our -cli- packages that install the standalone executable (cli11 powered)? Should they be installed by default with the main lib package (hence use Recommends)? What kind of dependency the meta-package gz-$collection should do with them?

Note that for Debian:

Recommends
        This declares a strong, but not absolute, dependency.       
        The Recommends field should list packages that would be found
        together with this one in all but unusual installations. 

Suggests
        This is used to declare that one package may be more useful with
        one or more others. Using this field tells the packaging system
        and the user that the listed packages are related to this one
        and can perhaps enhance its usefulness, but that installing this
        one without them is perfectly reasonable.

Currently listed as Suggests:

Package: libgz-launch6
Architecture: any
Section: libs
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: gz-launch6-cli
Breaks: libignition-launch6 (<< 5.999.999+nightly+git20220630+2rcec9c00a42bbd412815a3c9d64a3ce9b7dfd186d-2)
Replaces: libignition-launch6 (<< 5.999.999+nightly+git20220630+2rcec9c00a42bbd412815a3c9d64a3ce9b7dfd186d-2)
Multi-Arch: same
Description: Gazebo Launch Library - Launch libraries
 Gazebo Launch, a component of Gazebo, provides a command line
 interface to run and manager application and plugins.
 .
 Package contains the Gazebo launch libraries

Package: libgz-sim7
Architecture: any
Section: libs
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends},
         ${misc:Depends},
         qml-module-qtqml-models2
Suggests: gz-sim7-cli
Breaks: libignition-gazebo7 (<< 6.999.999+nightly+git20220630+2rcb61c01f8894e4f435f544d3511f346eaa753142-2)
Replaces: libignition-gazebo7 (<< 6.999.999+nightly+git20220630+2rcb61c01f8894e4f435f544d3511f346eaa753142-2)
Multi-Arch: same
Description: Gazebo Sim classes and functions for robot apps - Shared library
 Gazebo Sim is a component in the Gazebo framework, a set of libraries
 designed to rapidly develop robot applications.
 .
 Main shared library
 The package ships the Gazebo transport core development files


Package: libgz-transport12
Architecture: any
Section: libs
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: gz-transport12-cli
Breaks: libignition-transport12 (<< 11.999.999+nightly+git20220630+1r54abb8a6887e9137e6f703e51bbca2956efff773-1)
Replaces: libignition-transport12 (<< 11.999.999+nightly+git20220630+1r54abb8a6887e9137e6f703e51bbca2956efff773-1)
Multi-Arch: same
Description: Gazebo Transport Library - Shared library
 Gazebo transport library combines ZeroMQ with Protobufs to create a fast and
 efficient message passing system. Asynchronous message publication and
 subscription is provided along with service calls and discovery.

Listed as Recommends and installed by default:

Package: libgz-plugin2-dev
Architecture: any
Section: libdevel
Depends: libgz-plugin2 (= ${binary:Version}),
         libgz-cmake3-dev,
         libgz-utils2-cli-dev,
         libgz-utils2-dev,
         ${misc:Depends}
Breaks: libignition-plugin2-dev (<< 1.999.999+nightly+git20220630+1r3262c92257b72c3c82d788ae5aa1d54c464261e4-1)
Replaces: libignition-plugin2-dev (<< 1.999.999+nightly+git20220630+1r3262c92257b72c3c82d788ae5aa1d54c464261e4-1)
Multi-Arch: same
Recommends: gz-plugin2-cli
Description: Gazebo Plugin Library - Development files
 Gazebo Plugin is a component in the Gazebo framework, a set of libraries
 designed to rapidly develop robot applications.
 .
 Package contains the development files

ruby installations in install files:

find gz-*-release -name *.install -type f -exec grep -Hi ruby  {} \; | sed 's:.*debian/::'

libgz-gui.install:usr/lib/ruby/*/*
gz-launch-cli.install:usr/lib/ruby/*
libgz-msgs-dev.install:usr/lib/*/ruby/*/msgs[0-99]/*
libgz-msgs.install:usr/lib/ruby/gz/*.rb
libgz-plugin-dev.install:usr/lib/ruby/*/*
gz-sim-cli.install:usr/lib/ruby/gz/*.rb
libgz-transport-log.install:usr/lib/ruby/*/cmdlog[0-9][0-9].rb
gz-transport-cli.install:usr/lib/ruby/*/cmdtransport[0-9][0-9].rb

[scpeters]

I think the gz-garden metapackage should install all the -cli packages

[j-rivero]

I think the gz-garden metapackage should install all the -cli packages

gazebo-release/gz-garden-release#16

I left the issue open since there are other open questions.

[nkoenig]

Is the remaining question which package should host the .yaml and .rb files? If so, can they live in the -cli packages?

[azeey]

I've been putting the .yaml and .rb files in the non-dev packages per #529. I think it should not be required to install -dev packages in order to run these command line tools (whether via ruby or CLI11). The -dev packages bring in a lot more dependencies that are not really needed to run these tools.

What binary package should host the .yaml and .rb files that are part of gz submodules? Note that lib package should just contain the shared library, we don't want them in the -dev package and the -cli- package is most of the times not installed by default. In Debian the arch-independent files are typically using a -common package (see gazebo-common).

If the lib packages are supposed to contain only the shared library, then moving them to the -cli package makes sense to me. I believe the plan/hope is to transition to CLI11 for all our command line tools, so this will be a more permanent solution.

[j-rivero]

If the lib packages are supposed to contain only the shared library, then moving them to the -cli package makes sense to me. I believe the plan/hope is to transition to CLI11 for all our command line tools, so this will be a more permanent solution.

Does not sound bad to me. The only remaining question is: should the -cli- packages be installed as a soft dependency + by default of the main "libgzfoo" package? of "libgzfoo-dev" packages? If we don't don't move the current Suggests to Recommends we probably need to update many of our package documentation.

[azeey]

Making it a Recommends of libgzfoo would be best, I think.