[
https://issues.apache.org/jira/browse/BIGTOP-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799311#comment-13799311
]
Sean Mackrory commented on BIGTOP-1096:
---------------------------------------
I'm not sure I understand what you're saying. Replacing the two commands for
removing the tomcat-related alternatives with one remove-all command does not
resolve the problem for me. I assume the command as you're typed it as a typo,
and you meant "--remove-all oozie-tomcat-conf". As before, all the alternatives
symlinks are removed but all the actual configuration files remain. All the
other components only have one Tomcat-related alternative, so I don't see the
benefit of using remove-all in those components, and in fact this then
forcefully de-registers any configurations that the user may have added, so I
don't think we should do it unless it solves a bigger problem.
> 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)
