Ask Your Question
6

How can we reduce the amount of dependencies?

asked 2012-05-06 16:24:23 -0600

updated 2012-11-22 06:02:41 -0600

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
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages ...
(more)
edit retag flag offensive close merge delete

Comments

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

Eric Perko gravatar imageEric Perko ( 2012-05-06 16:32:39 -0600 )edit
1

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

joq gravatar imagejoq ( 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.

Patrick Bouffard gravatar imagePatrick Bouffard ( 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.

Eric Perko gravatar imageEric Perko ( 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?

joq gravatar imagejoq ( 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.

Eric Perko gravatar imageEric Perko ( 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

Eric Perko gravatar imageEric Perko ( 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

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

1 Answer

Sort by ยป oldest newest most voted
0

answered 2012-05-13 07:44:11 -0600

kwc gravatar image

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.

edit flag offensive delete link more

Comments

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

joq gravatar imagejoq ( 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

Eric Perko gravatar imageEric Perko ( 2012-05-15 15:49:18 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2012-05-06 16:24:23 -0600

Seen: 463 times

Last updated: Nov 22 '12