[ros-users] REP 122, REP 123, and REP 124: changes to ROS for ROS Fuerte

[Ken Conley]

On Fri, Feb 10, 2012 at 9:06 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:
> I admire the thought and hard work that went into this file system
> reorganization. It is a big step in the right direction. The
> documentation is clearly written and very helpful. I can imagine how
> difficult this task must be.
>
> As an old Unix developer I have a somewhat visceral reaction against
> putting machine-dependent binaries inside a share directory. I suppose
> it's too late to fix that for Fuerte, but it's just wrong, and almost
> anything would be better. This will not be easy to fix in a future
> release.
>
> There is no obvious choice for an alternative. Although "/lib" mostly
> contains libraries, there are actually quite a few executables in its
> subdirectories, and many more under "/usr/lib". So, I suggest
> something like "lib/ros/<ros-package-name>" in place of
> "share/<ros-package-name>". Another alternative might be "opt" (or
> just making something up), but "lib" seems better to me.
>
> Using "share/ros/<ros-package-name>" for genuine
> architecture-independent files (.xml, .yaml, etc.) is good, but not a
> requirement. There are advantages to keeping most or all installed
> files for a single package together.

NOTE: it is a requirement, for now, as it is the only way to find
package/stack-relative resources with the current implementation of
rospack/rosstack/roslaunch.  This is the crux of the problem (see
below).  i.e., lib or any other placement of binaries separate from
manifest.xml files will only work if roslaunch and rosrun are changed
(more on this below).

> The REP mentions a long-term intent to install with no prefix at all.
> That seems worthy, but a more realistic goal might be building with a
> "/usr" prefix. That fits the usual convention for distributing Debian
> or Ubuntu packages. I recommend consulting some Debian package
> developers. They have a lot of experience with this stuff, and
> probably have strong feelings about what should and should not be
> done.

"no prefix" was probably a bad choice of terminology. "/usr" (i.e.
platform default) was the intended meaning.  The intent was to try and
make clear that certain environment variables were only being set
because of the special /opt prefixing.  I've updated the REP to try
and clarify (diff attached).

>
> -0; I am sorry to be so critical. I completely agree with the intent
> of REP-0122. I really only object to one detail, but it's a big one.

Thanks for the feedback, the REP agrees with you on the issues with
share/.  The question mainly is what to do about it, and also what the
goal of the REP is.  Is the REP a waypoint towards the final goal, or
is it the goal itself? If it is a waypoint, is it the right waypoint?
If it is meant to be the final goal, then what are the necessary
changes?

The REP was intended to be a waypoint so that it could provide
necessary documentation for ROS Fuerte, but there are other ways of
filling that documentation need.  The lib/ suggestion above would
advance the waypoint a bit forward; it will need some more
specification to figure out how roslaunch/rosrun are supposed to find
the correct lib dir (i.e. manifest.xml files would have to go to lib/
instead, or there would need to be a separate lookup mechanism).  The
nice thing is that the converted stacks, thus far, have very few
package-relative binaries, so iterating on this portion of the spec is
easier.

As you can see with REP 125 (rosdep 2), part of the hope is to
redesign tools without package/stack crutches, and try and make the
vestigial bits drop away.  With the rosdep 2 changes, rosdep.yaml
files are no longer necessary in share/, which also means that
stack.xml files are no longer necessary in share/.  The next step is
to see if we can start getting rid of manifest.xml files (we tried,
but it ended up being a bit too much for backwards-compat), which
would fix performance issues with share.

roslaunch is difficult in this regard, as it was conceptualized
tightly on top of the ROS package system.  The long term solution may
be "don't use package-relative binaries".  That solution opens up a
can of worms; the biggest in my mind being that the roslaunch security
model changes drastically.  Before it was, "roslaunch can only execute
binaries within the ROS sandbox." Any solution that moves away from
this requires revisiting the roslaunch implementation (it should be
revisited).  Android uses the cleaner security model of just using
filesystem/iptables permissions, but that comes with a much more
advanced application harness.

 - Ken



> --
>  joq
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rep122.prefix
Type: application/octet-stream
Size: 3413 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120210/63435295/attachment-0004.obj>