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

Jack O'Quin jack.oquin at gmail.com
Sat Feb 11 01:03:55 UTC 2012


On Fri, Feb 10, 2012 at 4:23 PM, Ken Conley <kwc at willowgarage.com> wrote:
> On Fri, Feb 10, 2012 at 9:06 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:

>> 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).

My personal opinion is that the amount of architecture-independent
data in most packages is small enough to ignore for now. We may have
to deal with it some day to keep the OS packagers happy. I am not
expert enough at what they do.

>> 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).

Just a misunderstanding on my part. Without thinking about it much, I
assumed no prefix was intended for small, embedded controllers. While
/usr is the normal prefix for Linux binary packages, the default for
most build systems is still /usr/local.

> 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?

I saw that, and appreciate the fact that this issue had already been
considered. Most of my reaction had been formed before I even got that
far reading the REP. The /usr/share/ directory came along when network
filesystems became important in the late 1980's. Most robotics users
probably don't care much about that any more. Maybe some universities
who maintain large pools of shared machines do.

In my view, a REP, like an RFC or a PEP, defines an interface for
which multiple implementations are anticipated, what Fred Brooks
called "system architecture". No such definition is forever,
everything is a way-point in that sense. The trick is defining
interfaces that are stable enough to be useful, and flexible enough to
evolve as needed. Getting that right takes judgement and experience.
As Will Rogers put it: "good judgement comes from experience, and a
lot of that comes from bad judgement." :-)

> 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.

It all boils down to engineering tradeoffs. You understand these
issues far better than I do.

> 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.

Security is a big discussion. At some point the robotics community
will need to address it seriously. People are already starting to hack
into cars and appliances. I doubt many robotics researchers are
willing to deal with serious security in a networked environment.
Someday, we must.
-- 
 joq



More information about the ros-users mailing list