[ros-users] resolving open REP-0122 issues

[Jack O'Quin]

On Tue, Jul 24, 2012 at 2:19 PM, Dirk Thomas <dthomas at willowgarage.com> wrote:
> I am currently working on catkin and trying to get it in shape for a review.
> I am looking for a clean wet-only solution - and on-top of that add
> necessary stuff for backward compatibility with the dry world.

Good. I was not sure who was working on it.

> A new REP would be a very good idea - I would prepare one as soon as I have
> a thorough understanding of all details and a prototype with the necessary
> changes.
> It would if course be very welcome if you, Jack, (or anybody else) would put
> together a REP earlier.

Not trying to interfere, I am willing to help in any way that seems
useful. Working on documentation in parallel with you developing the
prototype might compress the overall deployment time and help us get
community buy-in sooner in the cycle.

IMHO, Fuerte got in trouble by not resolving this stuff early enough,
so I chose to give it a nudge.

> The most important issues currently are:
> - build-space should be equally usable as install-space (potentially
> chaining multiple of them without the need to install)

That should help a lot. It seems to mostly solve the "package
contents" issue mentioned in REP-0122 under "future work".

> - FHS compliance
> - catkin has no notion of a packages anymore (manifests only exist for
> backward compatibility), missing information must be ported from
> manifest.xml to stack.xml
> - a lot of tools are not working well with the wet world (i.e. rosdep)

I suspect that a large number of the user problems upgrading to Fuerte
are related to this.

Large, dry user repositories are going to exist for years. I see
making that work smoothly as an important goal for Groovy.

> Some comments regarding FHS compliance:
> Binaries of stacks can be installed in one of the following three locations
> to conform with the standard:
> - lib/STACK-NAME/libexec
>   looks like the most preferable solution
> - libexec/STACK-NAME
>   does not exist on several platform, which make it look weird
> - bin
>   not favorable since subfolders are not allowed in here

I dislike libexec. It is contrary to the Linux filesystem hierarchy
standard, and not supported on Debian or Ubuntu based systems. I
prefer lib/ros/STACK-NAME (or PACKAGE-NAME) in case ROS tools need to
search them, or just lib/STACK-NAME if we conclude that will not be
necessary.

Unfortunately, existing catkin packages are all going to be affected
by this change. When we fix it, let's at least introduce a build
variable to replace the explicit "share/" prefix.

> I agree that a tool like roscreate-stack should be created for the next
> release.

+1
-- 
 joq