[
https://issues.apache.org/jira/browse/BIGTOP-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799275#comment-13799275
]
Roman Shaposhnik commented on BIGTOP-1096:
------------------------------------------
[~mackrorysd] there appears to be some sort of a bug/feature of
update-alternatives --remove when more than one alternative is registered. The
good news is that there's an easy workaround (which also simplifies your patch
somewhat -- which is always welcome). Just replace this:
{noformat}
update-alternatives --remove oozie-tomcat-conf ${conf_tomcat}.http || :
update-alternatives --remove oozie-tomcat-conf ${conf_tomcat}.https || :
{noformat}
wit this:
{noformat}
update-alternatives --remove-all oozie-conf
{noformat}
Could you please do this for ALL of the components you've updated with tomcat
conf alternatives on the DEB side?
> alternatives within the alternatives-managed sub-directory could be harmful
> ---------------------------------------------------------------------------
>
> Key: BIGTOP-1096
> URL: https://issues.apache.org/jira/browse/BIGTOP-1096
> Project: Bigtop
> Issue Type: Bug
> Components: General
> Affects Versions: 0.7.0
> Reporter: Roman Shaposhnik
> Assignee: Sean Mackrory
> Priority: Blocker
> Fix For: 0.7.0
>
> Attachments:
> 0001-Addendum-to-BIGTOP-1096.-Correcting-location-of-Oozi.patch,
> 0001-BIGTOP-1096.-alternatives-within-the-alternatives-ma.patch
>
>
> I see that Oozie (at least) today creates a second level alternatives managed
> subdir (tomcat conf) under something that is already managed by an
> alternatives mechanism (oozie conf). This looks like it could be a problem if
> the user switches the top level one (oozie conf).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
