[
https://issues.apache.org/jira/browse/BIGTOP-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776052#comment-13776052
]
Bruno Mahé commented on BIGTOP-1080:
------------------------------------
{quote}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.{quote}
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.
{quote}I'd personally like Bigtop (and I am open to feedback) to be more less
conflicting and more co-existent with other distributions.{quote}
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.
{quote}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.{quote}
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.
> Change /usr/bin scripts to be alternatives instead of flat files
> ----------------------------------------------------------------
>
> Key: BIGTOP-1080
> URL: https://issues.apache.org/jira/browse/BIGTOP-1080
> Project: Bigtop
> Issue Type: Improvement
> Components: Debian, General, RPM
> Affects Versions: 0.7.0
> Reporter: Mark Grover
> Assignee: Mark Grover
> Fix For: 0.7.0
>
> Attachments: BIGTOP-1080.1.patch
>
>
> I think it would be a good idea to convert our /usr/bin scripts to be
> alternatives (i.e. symlinks) instead of flat files just like our
> configuration directories (/etc/component/config). It would make the package
> deployment more flexible for our users.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
