[
https://issues.apache.org/jira/browse/BIGTOP-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575499#comment-13575499
]
Roman Shaposhnik commented on BIGTOP-844:
-----------------------------------------
My only explanation of why it didn't work could be that I tried it on CentOS5
(this is the oldest RPM we have to deal with). Another possibility is that I
could've seen a *different* issue with condrestart not working (the one that is
currently masked by BIGTOP-844) and thought that the patch didn't help. Let me
re-run my experiments and attach the full logs.
> 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
>
> Attachments:
> 0001-BIGTOP-844.-Apache-Hadoop-rpm-upgrade-sequence-is-br.patch
>
>
> 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
