[
https://issues.apache.org/jira/browse/BIGTOP-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13574211#comment-13574211
]
Sean Mackrory commented on BIGTOP-844:
--------------------------------------
I don't know how practical this is or even if we would be able to update the
symlinks by that point in the upgrade sequence, but what about having versioned
JARs in separate directories and non-versioned symlinks to them in the
classpath? I do think that dropping the versions from names would be annoying
when trying to debug and ascertain which versions of each artifact is being
used, so if we do need to drop them to enable smoother upgrades, then I
definitely think we should provide another easy way to find that out.
> hadoop rpm upgrade sequence is broken
> -------------------------------------
>
> Key: BIGTOP-844
> URL: https://issues.apache.org/jira/browse/BIGTOP-844
> Project: Bigtop
> Issue Type: Bug
> Components: RPM
> Affects Versions: 0.5.0
> Reporter: Roman Shaposhnik
> Assignee: Roman Shaposhnik
> Fix For: 0.6.0
>
>
> Here's the deal -- during the RPM upgrade sequence there's a point in time
> when files that have different names in new and old package exist
> side-by-side. What it means for our style of hadoop packaging is that we'll
> have both /usr/lib/hadoop/foo-<old version>.jar and /usr/lib/hadoop/foo-<new
> version>.jar getting onto the classpath when we issue a condrestart for any
> service.
> This is pretty bad.
> At this point my knee jerk reaction is to re-evaluate why do we need
> versioned jars to begit with. Do you guys think there's any value in
> something like:
> * /usr/lib/hadoop/hadoop-common-2.0.0.jar
> vs a simple:
> * /usr/lib/hadoop/hadoop-common.jar
--
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
