| Summary: | resolving dependencies for JBoss EAP installation from live RHN server takes ages (more than 3 hours) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Peter Skopek <pskopek> |
| Component: | up2date | Assignee: | Clifford Perry <cperry> |
| Status: | CLOSED WONTFIX | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.9 | CC: | cperry, istudens, jhutar, jlanik, mmraka, nbronson |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-20 16:57:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Peter Skopek
2011-07-11 18:30:29 UTC
New EAP version has been pushed to RHN Live (5.1.1 version) and the installation still takes so much time. Why is this bugzilla being ignored? This hits our customer very badly! Please take care of it as soon as possible. Note that it hits EWP 5.1.1 as well. We have got work-around from Cliff Perry - uninstall rpmdevtools package (package from some internal, not shipped to customer, repo). Unfortunately, we (JBoss QA) haven't been using repository like this mentioned in our QA processes. Also hinted package we haven't be using anymore. I have checked this - provisioned machine (we have been using) from Beaker (latest production/stable RHEL4 release) doesn't deploy it to system. We have been using/subscribing only to RHN channels (at Live or Stage - situation seems the same) shipped to customer. Also note - issue was introduced around begin of July, previous months issue didn't occurred at all. This issue very hardly affect our work, please take care about it. Work-around from above isn't suitable for us. Hi Jan, thank you for investigation and useful info. I have tried your proposal version of up2date on RHEL4 i386 and x86_64 machine provisioned from Beaker (= RHEL4 U9). The whole installation procedure: up2date -i jbossas jbossas-messaging jbossas-ws-native was done in around 11 minutes, the most time wasting think was download packages. It is awesome progress from our actual speed:). But unfortunately, I hit next other problem with dependency resolving. Some package from above depends on codehaus-stax11. codehaus-stax11 depends still on codehaus-stax11-api. So the regular command time up2date jbossas jbossas-ws-native jbossas-messaging ended with: [root@nec-em24-1 ~]# time up2date jbossas jbossas-ws-native jbossas-messaging Fetching Obsoletes list for channel: rhel-i386-as-4... Fetching Obsoletes list for channel: jbappplatform-5-i386-as-4-rpm... Fetching Obsoletes list for channel: rhel-i386-as-4-extras... Fetching rpm headers... ######################################## Name Version Rel Arch ---------------------------------------------------------------------------------------- jbossas 5.1.1 16.ep5.el4 noarch jbossas-messaging 5.1.0 52.jdk6.ep5.el4 noarch jbossas-ws-native 5.1.1 16.ep5.el4 noarch Testing package set / solving RPM inter-dependencies... There was a package dependency problem. The message was: Unresolvable chain of dependencies: codehaus-stax11-1.1.2-4.2.3.jdk6.ep5.el4 requires codehaus-stax11-api = 0:1.1.2-4.2.3.jdk6.ep5.el4 The following packages were added to your selection to satisfy dependencies: Package Required by ---------------------------------------------------------------------------- codehaus-stax-api-1.2.0-0.2.ep5.el4.noarchjboss-deployers-2.0.10-4.ep5.el4 stax_1_0_api codehaus-stax-api-1.2.0-0.2.ep5.el4.noarchsun-fi-1.2.7-4.1.jdk6.ep5.el4 stax_1_0_api codehaus-stax-api-1.2.0-0.2.ep5.el4.noarchstax-ex-1.2-8.jdk6.ep5.el4 stax_1_0_api codehaus-stax-api-1.2.0-0.2.ep5.el4.noarchjettison-1.2-3.ep5.el4 stax_1_0_api codehaus-stax-api-1.2.0-0.2.ep5.el4.noarchjbosssx2-2.0.4-5.SP7.2.1.ep5.el4 stax_1_0_api codehaus-stax-api-1.2.0-0.2.ep5.el4.noarchglassfish-jaxws-2.1.7-0.20.jdk6.ep5.el4 stax_1_0_api codehaus-stax-api-1.2.0-0.2.ep5.el4.noarchjboss-security-xacml-2.0.5-1.jdk6.ep5.el4stax_1_0_api xml-commons-jaxp-1.2-apis-1.3.04-7.10.jdk6.ep5.el4.noarchdom4j-1.6.1-11.ep5.el4 jaxp xml-commons-jaxp-1.3-apis-1.3.04-7.10.jdk6.ep5.el4.noarchjboss-common-logging-log4j-2.1.2-1.ep5.el4xml-commons-apis real 1m18.504s user 0m3.645s sys 0m0.539s [root@nec-em24-1 ~]# Also manual installation of codehouse-stax11 ended with error: [root@tyan-gt24-10 ~]# up2date codehaus-stax11 Fetching Obsoletes list for channel: rhel-x86_64-as-4... Fetching Obsoletes list for channel: jbappplatform-5-x86_64-as-4-rpm... Fetching Obsoletes list for channel: rhel-x86_64-as-4-extras... Fetching rpm headers... ######################################## Name Version Rel Arch ---------------------------------------------------------------------------------------- codehaus-stax11 1.1.2 4.2.3.jdk6.ep5.el4 noarch Testing package set / solving RPM inter-dependencies... There was a package dependency problem. The message was: Unresolvable chain of dependencies: codehaus-stax11-1.1.2-4.2.3.jdk6.ep5.el4 requires codehaus-stax11-api = 0:1.1.2-4.2.3.jdk6.ep5.el4 The following packages were added to your selection to satisfy dependencies: Package Required by ---------------------------------------------------------------------------- [root@tyan-gt24-10 ~]# But if I follow the chain step by step from codehaus-stax11-api, codehaus-stax11 and after that the original command, everything works fine. Ufff... (codehaus-stax11-api is present in channel all the time of course) Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue. |