On Sat, Feb 11, 2012 at 11:35 AM, Ken Conley <kwc@willowgarage.com> wrote:
> On Sat, Feb 11, 2012 at 10:46 AM, Bill Morris
> <bill@iheartengineering.com> wrote:
>> On Fri, 2012-02-10 at 14:01 -0800, Brian Gerkey wrote:
>>> On Fri, Feb 10, 2012 at 9:06 AM, Jack O'Quin <jack.oquin@gmail.com> 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/<ros-package-name>" in place of
>>> > "share/<ros-package-name>". Another alternative might be "opt" (or
>>> > just making something up), but "lib" seems better to me.
>>> >
>>> > 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.
>>>
>>> You have a point there.  We could easily go into
>>> "lib/<ros-package-name>".    We'd just have point ROS_PACKAGE_PATH to
>>> lib instead of share, and CMake will find things in
>>> "lib/<ros-package-name>/cmake" the same as it will in
>>> "share/<ros-package-name>/cmake."
>>>
>>> Now, if we want to go into "lib/ros/<ros-package-name>," 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?
>>
>> Putting binaries in share seems strange to me as well. I would prefer
>> something like the bsd concept of libexec [1] or
>> lib/ros/<ros-package-name>. lib/<ros-package-name> seems like it will
>> cause namespace problems and clutter.
>
> Thanks for the pointer about libexec.  Learned something new and got
> to read through other debates that are similar to this:
>
> http://lists.debian.org/debian-devel/2005/05/msg00401.html
>
> lib/ is, as Jack and you have well-argued, the correct choice.
> libexec/ would be a nice choice if we didn't have to package on
> Debian/Ubuntu.  A lib/ros/<ros-package-name> scheme would provide good
> sandboxing for the executables that roslaunch can invoke.  REP 123
> would have to be updated with a new environment variable so that the
> location of 'lib' can be found.
>
> We can start working on implementation changes post-Fuerte and have
> this well-formed for Groovy.  Stacks that are converted to catkin in
> Fuerte will need to be branched, but as we have kept this set
> intentionally small, it should not be too difficult.

FWIW, switching from share/<ros-package-name> to
lib/<ros-package-name> should be easy and low-risk.  If that's
preferred to share/<ros-package-name>,  it could be done for Fuerte.
Switching to share/ros/<ros-package-name> is riskier, but can be
easily tested.  I'll look into it.

	brian.