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

[Brian Gerkey]

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

We've talked about this more, and have decided to leave everything
where it is for Fuerte (i.e., all package-relative assets, including
executables, go in share/<ros-package-name>), but remove that part of
the layout specification from REP 122.  The reasoning is that we don't
yet have an answer that we're ready to prescribe.  We'll aim to sort
it out properly by Groovy.

	brian.