On Fri, Feb 10, 2012 at 9:06 AM, Jack O'Quin 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/" in place of > "share/". Another alternative might be "opt" (or > just making something up), but "lib" seems better to me. > > 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). > 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@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users