[
https://issues.apache.org/jira/browse/BIGTOP-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Mackrory updated BIGTOP-1096:
----------------------------------
Attachment: 0001-Addendum-to-BIGTOP-1096.-Correcting-location-of-Oozi.patch
Some package tests are failing because /etc/oozie doesn't get cleaned up. I
thought this was because of the problem this patch fixes - the path was wrong
preventing the new tomcat-deployment alternatives from getting cleaned up.
On a fresh install I still have the problem however. The alternatives are
removed, but the raw config files remain (although the symlinks to
/usr/lib/oozie/webapps get deleted). I've compared the hashes of the package
contents, the contents immediately after install, and the contents after
removing the package, and I don't see any other modification. These aren't
files that are created or deleted in scripts - they're entirely within the
package archive. I'm quite stumped...
> 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)
