You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by "Roman Shaposhnik (Created) (JIRA)" <ji...@apache.org> on 2012/01/19 03:08:40 UTC
[jira] [Created] (BIGTOP-357) libjvm.so dependency on CentOS can
only be satisfied by libgcj in some cases
libjvm.so dependency on CentOS can only be satisfied by libgcj in some cases
----------------------------------------------------------------------------
Key: BIGTOP-357
URL: https://issues.apache.org/jira/browse/BIGTOP-357
Project: Bigtop
Issue Type: Bug
Components: RPM
Reporter: Roman Shaposhnik
Assignee: Roman Shaposhnik
This is one of the unfortunate side effect of us not really being able to depend on JDK in a proper packaged way. Currently the hadoop package quite rightfully depends on libjvm.so but the trouble is that Sun/Oracle JDK RPM package doesn't really "provide" libjvm.so from RPM/YUM perspective (Sun/Oracle JDK RPM package in general cuts a lot of corners in packaging -- that's just one of them).
What this leads to is that YUM keeps looking for packages that DO provide libjvm.so and in some cases the only one is libgcj. Thus the end result is for a user to see weird dependency on libgcj when installing hadoop package. It should be noted that this is harmless. The right libjvm.so (from Sun/Oracle JDK) is used during execution and libgcj is just quietly sitting there.
As a side note, in a true enterprise case (RHEL) the right thing happens -- a properly packaged JDK from RHEL channel gets pulled.
Now, it would be nice if RPM has an option of disabling just THAT one auto dependency (on libjvm.so) but I'm not aware of such a thing. Hence this fix disables ALL of our automatic dependencies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BIGTOP-357) libjvm.so dependency on CentOS can
only be satisfied by libgcj in some cases
Posted by "Roman Shaposhnik (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roman Shaposhnik updated BIGTOP-357:
------------------------------------
Fix Version/s: 0.4.0
> libjvm.so dependency on CentOS can only be satisfied by libgcj in some cases
> ----------------------------------------------------------------------------
>
> Key: BIGTOP-357
> URL: https://issues.apache.org/jira/browse/BIGTOP-357
> Project: Bigtop
> Issue Type: Bug
> Components: RPM
> Reporter: Roman Shaposhnik
> Assignee: Roman Shaposhnik
> Fix For: 0.4.0
>
> Attachments: BIGTOP-357.patch.txt
>
>
> This is one of the unfortunate side effect of us not really being able to depend on JDK in a proper packaged way. Currently the hadoop package quite rightfully depends on libjvm.so but the trouble is that Sun/Oracle JDK RPM package doesn't really "provide" libjvm.so from RPM/YUM perspective (Sun/Oracle JDK RPM package in general cuts a lot of corners in packaging -- that's just one of them).
> What this leads to is that YUM keeps looking for packages that DO provide libjvm.so and in some cases the only one is libgcj. Thus the end result is for a user to see weird dependency on libgcj when installing hadoop package. It should be noted that this is harmless. The right libjvm.so (from Sun/Oracle JDK) is used during execution and libgcj is just quietly sitting there.
> As a side note, in a true enterprise case (RHEL) the right thing happens -- a properly packaged JDK from RHEL channel gets pulled.
> Now, it would be nice if RPM has an option of disabling just THAT one auto dependency (on libjvm.so) but I'm not aware of such a thing. Hence this fix disables ALL of our automatic dependencies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BIGTOP-357) libjvm.so dependency on CentOS can
only be satisfied by libgcj in some cases
Posted by "Peter Linnell (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188882#comment-13188882 ]
Peter Linnell commented on BIGTOP-357:
--------------------------------------
+1 LTGM
> libjvm.so dependency on CentOS can only be satisfied by libgcj in some cases
> ----------------------------------------------------------------------------
>
> Key: BIGTOP-357
> URL: https://issues.apache.org/jira/browse/BIGTOP-357
> Project: Bigtop
> Issue Type: Bug
> Components: RPM
> Reporter: Roman Shaposhnik
> Assignee: Roman Shaposhnik
> Attachments: BIGTOP-357.patch.txt
>
>
> This is one of the unfortunate side effect of us not really being able to depend on JDK in a proper packaged way. Currently the hadoop package quite rightfully depends on libjvm.so but the trouble is that Sun/Oracle JDK RPM package doesn't really "provide" libjvm.so from RPM/YUM perspective (Sun/Oracle JDK RPM package in general cuts a lot of corners in packaging -- that's just one of them).
> What this leads to is that YUM keeps looking for packages that DO provide libjvm.so and in some cases the only one is libgcj. Thus the end result is for a user to see weird dependency on libgcj when installing hadoop package. It should be noted that this is harmless. The right libjvm.so (from Sun/Oracle JDK) is used during execution and libgcj is just quietly sitting there.
> As a side note, in a true enterprise case (RHEL) the right thing happens -- a properly packaged JDK from RHEL channel gets pulled.
> Now, it would be nice if RPM has an option of disabling just THAT one auto dependency (on libjvm.so) but I'm not aware of such a thing. Hence this fix disables ALL of our automatic dependencies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BIGTOP-357) libjvm.so dependency on CentOS can
only be satisfied by libgcj in some cases
Posted by "Roman Shaposhnik (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roman Shaposhnik updated BIGTOP-357:
------------------------------------
Attachment: BIGTOP-357.patch.txt
> libjvm.so dependency on CentOS can only be satisfied by libgcj in some cases
> ----------------------------------------------------------------------------
>
> Key: BIGTOP-357
> URL: https://issues.apache.org/jira/browse/BIGTOP-357
> Project: Bigtop
> Issue Type: Bug
> Components: RPM
> Reporter: Roman Shaposhnik
> Assignee: Roman Shaposhnik
> Attachments: BIGTOP-357.patch.txt
>
>
> This is one of the unfortunate side effect of us not really being able to depend on JDK in a proper packaged way. Currently the hadoop package quite rightfully depends on libjvm.so but the trouble is that Sun/Oracle JDK RPM package doesn't really "provide" libjvm.so from RPM/YUM perspective (Sun/Oracle JDK RPM package in general cuts a lot of corners in packaging -- that's just one of them).
> What this leads to is that YUM keeps looking for packages that DO provide libjvm.so and in some cases the only one is libgcj. Thus the end result is for a user to see weird dependency on libgcj when installing hadoop package. It should be noted that this is harmless. The right libjvm.so (from Sun/Oracle JDK) is used during execution and libgcj is just quietly sitting there.
> As a side note, in a true enterprise case (RHEL) the right thing happens -- a properly packaged JDK from RHEL channel gets pulled.
> Now, it would be nice if RPM has an option of disabling just THAT one auto dependency (on libjvm.so) but I'm not aware of such a thing. Hence this fix disables ALL of our automatic dependencies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BIGTOP-357) libjvm.so dependency on CentOS can
only be satisfied by libgcj in some cases
Posted by "Bruno Mahé (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188886#comment-13188886 ]
Bruno Mahé commented on BIGTOP-357:
-----------------------------------
+1
> libjvm.so dependency on CentOS can only be satisfied by libgcj in some cases
> ----------------------------------------------------------------------------
>
> Key: BIGTOP-357
> URL: https://issues.apache.org/jira/browse/BIGTOP-357
> Project: Bigtop
> Issue Type: Bug
> Components: RPM
> Reporter: Roman Shaposhnik
> Assignee: Roman Shaposhnik
> Attachments: BIGTOP-357.patch.txt
>
>
> This is one of the unfortunate side effect of us not really being able to depend on JDK in a proper packaged way. Currently the hadoop package quite rightfully depends on libjvm.so but the trouble is that Sun/Oracle JDK RPM package doesn't really "provide" libjvm.so from RPM/YUM perspective (Sun/Oracle JDK RPM package in general cuts a lot of corners in packaging -- that's just one of them).
> What this leads to is that YUM keeps looking for packages that DO provide libjvm.so and in some cases the only one is libgcj. Thus the end result is for a user to see weird dependency on libgcj when installing hadoop package. It should be noted that this is harmless. The right libjvm.so (from Sun/Oracle JDK) is used during execution and libgcj is just quietly sitting there.
> As a side note, in a true enterprise case (RHEL) the right thing happens -- a properly packaged JDK from RHEL channel gets pulled.
> Now, it would be nice if RPM has an option of disabling just THAT one auto dependency (on libjvm.so) but I'm not aware of such a thing. Hence this fix disables ALL of our automatic dependencies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira