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

[Ken Conley]

On Fri, Feb 10, 2012 at 5:03 PM, Jack O'Quin <jack.oquin at gmail.com> wrote:
> 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.

That interface notion is a good perspective on this.  One possibility
to satisfy the various needs is to pull the share/ part of the REP as
its not fully baked. For documentation purposes, I can put it in a
Future Work section, along with a summary of the proposals around lib/
that you and Bill have put forth.  A future REP can then easily come
in and add to the specification.

Thoughts?

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

... I'm building up my stock of good judgement then :) ...

 - Ken

>
>> 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
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users