[
https://issues.apache.org/jira/browse/BIGTOP-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575356#comment-13575356
]
Konstantin Boudnik commented on BIGTOP-844:
-------------------------------------------
Bad stuff indeed.
Drifting away from the versioned jars will certainly clobber this issue during
upgrades, but it might make it worst by not manifesting the version of the libs
in the product.
> 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
