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?

 - Ken

>
>        brian.
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users