On Sat, Feb 11, 2012 at 3:28 PM, Ken Conley <kwc@willowgarage.com> wrote:
> On Sat, Feb 11, 2012 at 1:50 PM, Brian Gerkey <gerkey@willowgarage.com> wrote:
>> 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.

> By 'low-risk' I assume you mean amending the spec so that
> manifest/launch/etc... files go in lib/ as well?  Or do you mean
> changing the find_node() code?

Yeah, the low-risk option is to install all package-relative assets to
lib/<ros-package-name> instead of share/<ros-package-name>.  It would
just require updating the existing catkin-installed packages, and the
ROS_PACKAGE_PATH setting in the generated shell file.

It would seem that there's enough desire to pull binaries out of
share/ to make this change.  But it would be good to understand what
it would take to make lib/ros/<ros-package-name> work, as that would
be better.

	brian.