On Fri, Feb 10, 2012 at 5:03 PM, Jack O'Quin wrote: > On Fri, Feb 10, 2012 at 4:23 PM, Ken Conley wrote: >> On Fri, Feb 10, 2012 at 9:06 AM, Jack O'Quin wrote: > >>> Using "share/ros/" 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@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users