[ros-users] REP 122, REP 123, and REP 124: changes to ROS for ROS Fuerte

[Ken Conley]

On Sat, Feb 11, 2012 at 10:46 AM, Bill Morris
<bill at 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 at 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.

REP 122, 123, and 124 are all fully affected, so they will necessarily
remain in Draft status for now.

 - Ken


> ...
>
> [1]
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dirstructure.html
>
>
> --
> Bill Morris <bill at iheartengineering.com>
> I Heart Engineering
> http://www.iheartengineering.com
> <3
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users