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

[Brian Gerkey]

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?

> The REP mentions a long-term intent to install with no prefix at all.
> That seems worthy, but a more realistic goal might be building with a
> "/usr" prefix. That fits the usual convention for distributing Debian
> or Ubuntu packages. I recommend consulting some Debian package
> developers. They have a lot of experience with this stuff, and
> probably have strong feelings about what should and should not be
> done.

I believe that "non-prefixed installs" is meant to refer to installing
the standard system location, which would usually be /usr.

> -0; I am sorry to be so critical. I completely agree with the intent
> of REP-0122. I really only object to one detail, but it's a big one.

No apologies; we want criticism, especially the constructive sort.

	brian.