# How can we reduce the amount of dependencies?

I recall that one of the highlights of Diamondback was to have separated the "GUI vs. non-GUI" components. While I think this was achieved to a degree*, it seems there is still a long way to go even in Fuerte. For example, many packages depend on TF, which is clearly not a GUI-only thing. But the TF stack (and hence the Debian package that many people will install to get it) has dependencies that bring in a lot of GUI related stuff. Fonts, even (note ttf-dejavu-core in the apt-get output below).

For those of us whose robots are headless, with limited hard drive space, and/or have to download package updates over a slower connection, all these X related packages are undesirable overhead. I doubt I'm alone in having such concerns (though admittedly I'm likely in the minority).

Of course I could file a ticket for the specific problem with geometry/tf but it seems to me that this issue is something that occurs in many of the core stacks/packages. Is this something that could be made once again an area of focus for the upcoming Groovy release?

* To what degree is debatable--the diamondback wiki page mentions the navigation stack as an example of lighter dependencies. But navigation still depends on geometry...

Here is what my system wants me to install in order to use the TF library:

$sudo apt-get install ros-fuerte-geometry Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: build-essential dpkg-dev fontconfig fontconfig-config fonts-liberation freeglut3 freeglut3-dev graphviz libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libblas3gf libcairo2 libcdt4 libcgraph5 libcppunit-1.12-1 libcppunit-dev libdatrie1 libdb4.8 libdpkg-perl libdrm-dev libeigen3-dev libfontconfig1 libgd2-noxpm libgfortran3 libgl1-mesa-dev libgl1-mesa-glx libglapi-mesa libglu1-mesa libglu1-mesa-dev libgraph4 libgvc5 libgvpr1 libice-dev libjpeg-turbo8 libjpeg8 libkms1 liblapack3gf libneon27-gnutls libpango1.0-0 libpathplan4 libpthread-stubs0 libpthread-stubs0-dev libsm-dev libsvn1 libthai-data libthai0 libx11-dev libx11-doc libx11-xcb1 libxau-dev libxcb-glx0 libxcb-render0 libxcb-shm0 libxcb1-dev libxdmcp-dev libxext-dev libxft2 libxt-dev libxxf86vm1 mesa-common-dev python-numpy python-sip python-sip-dev ros-fuerte-bullet ros-fuerte-common-rosdeps ros-fuerte-orocos-kinematics-dynamics subversion ttf-dejavu-core ttf-liberation x11proto-core-dev x11proto-input-dev x11proto-kb-dev x11proto-xext-dev xorg-sgml-doctools xtrans-dev Suggested packages: debian-keyring gsfonts graphviz-doc libqttestrunner1c2a libcppunit-doc libeigen3-doc libgd-tools ttf-baekmuk ttf-arphic-gbsn00lp ttf-arphic-bsmi00lp ttf-arphic-gkai00mp ttf-arphic-bkai00mp libxcb-doc python-numpy-doc python-numpy-dbg gfortran python-sip-doc subversion-tools db4.8-util The following NEW packages will be installed: build-essential dpkg-dev fontconfig fontconfig-config fonts-liberation freeglut3 freeglut3-dev graphviz libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libblas3gf libcairo2 libcdt4 libcgraph5 libcppunit-1.12-1 libcppunit-dev libdatrie1 libdb4.8 libdpkg-perl libdrm-dev libeigen3-dev libfontconfig1 libgd2-noxpm libgfortran3 libgl1-mesa-dev libgl1-mesa-glx libglapi-mesa libglu1-mesa libglu1-mesa-dev libgraph4 libgvc5 libgvpr1 libice-dev libjpeg-turbo8 libjpeg8 libkms1 liblapack3gf libneon27-gnutls libpango1.0-0 libpathplan4 libpthread-stubs0 libpthread-stubs0-dev libsm-dev libsvn1 libthai-data libthai0 libx11-dev libx11-doc libx11-xcb1 libxau-dev libxcb-glx0 libxcb-render0 libxcb-shm0 libxcb1-dev libxdmcp-dev libxext-dev libxft2 libxt-dev libxxf86vm1 mesa-common-dev python-numpy python-sip python-sip-dev ros-fuerte-bullet ros-fuerte-common-rosdeps ros-fuerte-geometry ros-fuerte-orocos-kinematics-dynamics subversion ttf-dejavu-core ttf-liberation x11proto-core-dev x11proto-input-dev x11proto-kb-dev x11proto-xext-dev xorg-sgml-doctools xtrans-dev 0 upgraded, 77 newly installed, 0 to remove and 0 not upgraded. Need to get 32.4 MB of archives. After this operation, 107 MB of additional disk space will be used.  UPDATE: It looks like groovy resolves this problem, yay!: $ sudo apt-get install ros-groovy-tf
Building dependency tree
The following packages ...
edit retag close merge delete

A lot of this is probably due to view_frames using graphviz to generate the TF tree...

( 2012-05-06 16:32:39 -0600 )edit
1

I agree this is a problem. Let's open an enhancement ticket.

( 2012-05-06 18:17:29 -0600 )edit

@Eric Perko, yes I think view_frames is the primary culprit in the case of tf. But I think a lot of dependencies get brought in because of tf_conversions as well. @joq: I can certainly open a ticket against geometry but what I'd really like to hear is how to get this looked at generally for Groovy.

( 2012-05-07 06:17:49 -0600 )edit

@Patrick Bouffard: This type of thing is probably a good topic for one of the Groovy SIGs (which may not have started forming yet). Also, it looks like the tf_conversions are pretty light (besides tf which has that graphviz dependency), only needing tf, Eigen, geometry_msgs and KDL.

( 2012-05-07 07:59:40 -0600 )edit

+1 on the SIG approach. It's about time for Groovy SIGs to form, now. Not so clear which group should focus on it, though. Do we need a packaging SIG?

( 2012-05-07 08:25:43 -0600 )edit

Perhaps... really it seems this should have been taken care of already in Electric. See http://ros.org/reps/rep-0113.html . It notes that the robot variant may not have any GUI dependencies, but clearly geometry (which is part of the robot variant) does.

( 2012-05-07 09:43:48 -0600 )edit

Maybe a packaging/infrastructure SIG could put some rules into the deb builders to throw errors if something that is part of the robot variant depends on some set of GUI packages like x11 or OpenGL related things... Sort of a transitive dependency deb blacklist that would prevent a build w/ GUI stuf

( 2012-05-07 09:45:51 -0600 )edit

I wonder how widespread this problem is. Is geometry an abnormal example? The geometry2 sources look cleaner: https://kforge.ros.org/geometry/experimental

( 2012-05-07 12:06:47 -0600 )edit

Sort by » oldest newest most voted

There is already a geometry_visualization stack, so I think it's mainly a matter of moving any remaining visualizers out of tf into there, which is not too difficult (mainly documentation that needs to be fixed). Geometry will likely already be going into a massive rework to catkinize it in Groovy, so I imagine someone willing to help expedite the move (e.g. finding references to the viewer that need to be fixed) would be beneficial.

I'm not sure what is the motivation behind:

"Of course I could file a ticket for the specific problem with geometry/tf but it seems to me that this issue is something that occurs in many of the core stacks/packages."

We focused on cleaning up all the issues that we spotted back in Diamondback/Electric. Some areas may have been missed. Unless you can name more examples, I don't see why filing a ticket/patch is the wrong approach here. With Fuerte, we're at the point where ROS dependencies are becoming very granular.

more

Filing tickets seems a good way to get things fixed. Dynamic reconfigure is another problem dependency that affects many drivers: https://kforge.ros.org/dynamicreconfig/trac/ticket/3

( 2012-05-15 15:27:27 -0600 )edit

One place a SIG (like the infrastructure SIG from Fuerte) could focus is something like adding rules for the deb-building process such that e.g. any package in the fuerte-robot variant cannot have a transitive dependency on e.g. Wx, Qt, X11 etc. This could be a good way to verify a GUI free variant

( 2012-05-15 15:49:18 -0600 )edit