On Fri, Feb 10, 2012 at 9:06 AM, Jack O'Quin wrote: > 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. You have a point there. We could easily go into "lib/". We'd just have point ROS_PACKAGE_PATH to lib instead of share, and CMake will find things in "lib//cmake" the same as it will in "share//cmake." Now, if we want to go into "lib/ros/," then we'd have to play with the CMake infrastructure some to make things like 'find_package(roscpp)' work properly. How important do you think it is to have the intermediate "ros" directory in there? > 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. I believe that "non-prefixed installs" is meant to refer to installing the standard system location, which would usually be /usr. > -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. No apologies; we want criticism, especially the constructive sort. brian.