On Tue, Jul 24, 2012 at 2:19 PM, Dirk Thomas 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