I think it would be nice to be able to run multiple versions of say, pig, against the same cluster. While this change doesn't achieve that for us on its own, it's a step in that direction. Alternatives provide a convenient way to switch over bin scripts.
We do not package more than one version of pig. So in an Apache Bigtop context, I do not see the issue. In a non-Apache Bigtop context, see further down.
Also the usual way to deal with multiple versions of a package is to suffix the scripts/packages with their versions. See packages python vs python26 on centos 5. Or see also packages for Apache Flume 1 and 2 in Apache Bigtop a few month ago.
I would lean toward having versions appended to the scripts since it would make the version being used more obvious. Also if we need to package more than one version, it means they are not compatible/interchangeable since each version fulfill a different need. Therefore having multiple versions behind the same alternative would only add confusion and complexity.
I'd personally like Bigtop (and I am open to feedback) to be more less conflicting and more co-existent with other distributions.
So do I. But Apache Bigtop taking unilateral actions will not foster consensus. Other distributions have other requirements and needs. And this patch may or may not accommodate these needs and requirements.
We should get people from other distributions involved in the first place so we can all agree on a solution and implement it. I can volunteer to ping some of the fedora folks to help get this started and see if they are interested.
While I appreciate the intent of this ticket, I do not agree with this patch (unless this idea gets sold to most distributions or I am missing something). This patch may still have the very same issues it is trying to fix. For instance what if other distributions decide to not honor the alternatives set up for the bin scripts? We would end up with the same conflicting paths and additional complexity.
this change doesn't do that completely, it's a change in that direction, where the symlinks for bin scripts (and if followed by other distributions) would co-exist.
I would also encourage you to write down your plan on the wiki or mailing-list. This would enable the community to review your plan and give some feedback before you spend any time working on it. And you may even get volunteers for some of the work.
It would also provide some very useful context to your patches.
So for now I would rather not commit this patch and wait to see how the community wants to deal with multiple distributions of some of our projects.