Release as debian

[NikolausDemmel]

Any chance of releasing this as a debian into indigo (and jade)? Is there substantial effort or some open issue, or is it more about finding the time to do the release?

[wjwwood]

There is this list, some of which cannot be overcome, but others might could be improved:

https://github.com/catkin/catkin_simple#known-limitations

Also, we wanted to change the name, since it really is ROS specific (it auto generate messages, dynamic reconfigure, etc. which are all ROS specific and catkin doesn't really know anything about), but never got around to it. I think it could also benefit from considering package.xml format 2 dependency tags separately, when they're available: #7

I always wanted to see more documentation as well, but I haven't found time outside of what I spend on catkin_tools to accomplish any of those items.

I think the name change is the most important thing (or at least the highest impact change to users which we could delay) to consider before doing a proper release. These were the names I can remember discussing:

• ros_cmake_auto
  • follows the pattern of ament_cmake_auto, which does a similar thing in ROS 2: https://github.com/ament/ament_cmake/tree/master/ament_cmake_auto
    • That's still a work in progress, but the design changes in ament make it possible to avoid some of the issues listed in https://github.com/catkin/catkin_simple#known-limitations
    • Also, unlike this package, ament_cmake_auto is extensible, so it can allow something to extend it to auto generate messages, for example, without that package knowing about it (root of the reason to change the name of this package)
• catkin_auto
• catkin_ros
• catkin_ros_auto

I don't remember any more off the top of my head. Most of them play off the auto hint or try to paint this as a catkin/ros compatibility package, like gazebo_ros or stage_ros, this is catkin_ros.

If you're interested, you could take over and release it. Or you could fork it as is and release it under a different name. I'm not sure when I'd have time to accomplish these things and then do a release. If I had help fixing up the last few items, I could make a release. I'd also be willing to give maintainership over to someone else with more bandwidth to make this happen.

[NikolausDemmel]

I see. Thanks for the explanation. I only recently starting trying catkin_simple, so I will for now continue using it from source to get a feel on the practical implications of the limitations.

I agree that support for format 2 and more documentation are important, but maybe not absolutely required for a (beta) release.

As for the name change. My impromptu favorites are: catkin_cmake_auto_ros > catkin_cmake_ros_auto > catkin_auto_ros > catkin_ros_auto > catkin_auto > catkin_simple.

Although if we would choose something that does not have ros in it, we might as well stick with catkin_simple, which is not too bad of a name IMO, except for the missing ROS reference. One needs to also pick a fitting (and short) prefix for the cmake macros. cs_ is pretty neat.

[wjwwood]

My slight preference is for catkin_ros_auto, which could be suffixed as cra_.

[wxmerkt]

Hey @wjwwood,
I'd like to follow up on this issue - what are the current thoughts on releasing it as a Debian/what is blocking?

Thanks,
Wolfgang

[NikolausDemmel]

Hi @wxmerkt, I think the main points from the comment above #29 (comment) still remain. The name should be changed (catkin_ros_auto?) and some of the limitations should best be addressed.

There is some work in progress (at some point I ran out of time to work on this):

• Also include buildtool-depends in find_package(catkin ...) #31
• Check for exported packages in build(tool)-export depends, not run-depends. ros/catkin#790
• Allow indirect buildtool-depend on catkin ros/catkin#789 (comment)