add archlinux to kinetic

[protobits]

This allows bloom to identify archlinux as supported distribution, as per bchretien/arch-ros-stacks#50
In that issue the changes required to support archlinux are being discussed. Currently, a modified bloom version which allows to generate the required build files was proposed and successfully tested. This addition to rosdistro will allow the modified bloom to be proposed as a PR and tested by others. Since the buildfarm does not yet have support for archlinux, this addition to the distributions file should be inoccuous.

[wjwwood]

The release platforms need to be alphabetical for CI to pass.

[tfoote]

I would rather hold this until we've validated that there's something which can use it successfully. Otherwise people will find this here and then expect tools for Arch which don't exist yet.

And our general policy is not to add new platforms to an existing rosdistro. The problem with adding platforms is that it requires all maintainers to validate their packages on the new platform and rerun bloom.

During the development and testing it seems like using the ROSDISTRO_INDEX_URL would relatively easily allow testing before merging this. Using a fork would also support using alternative release repositories where test releases can be made with the prototype bloom versions.

[dirk-thomas]

What is the status of this? Should this target the upcoming Lunar distribution instead (see #13676.)?

[tfoote]

I'm going to close this as I don't think it makes sense to add arch to Kinetic builds. And Lunar is pretty settled as well now too. We could consider adding it for M-Turtle when we discuss the target platforms to update for REP-3 http://www.ros.org/reps/rep-0003.html

When we consider it for M-Turtle it would be great to have a prototype of the bloom functionality for arch so we can know it's deployable and won't break people's releases.

Adding this will also require that all releases have arch rosdep keys or else explicitly skip arch. So we want to make sure that we know it's not going to cause too much more effort for maintainers. So an effort to audit existing rosdep keys for core packages availability on arch would also be valuable when making this decision in the future.