Description of problem: Javassist-javadoc package from rhel-server-optional-6 has dependency on javassist package in the same channel. When trying to install javassist package from jbappplatform-6-server-6-rpm it fails, due to dependency on javassist-javadoc. Customer can possible face this problem if he has javassist* from rhel channels, installed. Version-Release number of selected component (if applicable): 6.3.0 How reproducible: always Steps to Reproduce: 1. Subscribe to the following channels: jbappplatform-6-server-6-rpm rhel-server-optional-6 rhel-ARCH-server-6 2. yum --disablerepo='jbappplatform-6-*' install javassist javassist-javadoc -y 3. yum -y groupinstall jboss-eap6 4. yum list available --disablerepo='*' --enablerepo=jbappplatform* | grep -v jboss-on-agent | awk '{ print $1 }' | xargs yum install -y Actual results: Error: Package: javassist-javadoc-3.9.0-6.el6.noarch (@rhel-ppc64-server-optional-6) Requires: javassist = 3.9.0-6.el6 Removing: javassist-3.9.0-6.el6.noarch (@rhel-ppc64-server-optional-6) javassist = 3.9.0-6.el6 Updated By: javassist-3.15.0-5.GA_redhat_2.ep6.el6.3.noarch (jbappplatform-6-ppc64-server-6-rpm) javassist = 3.15.0-5.GA_redhat_2.ep6.el6.3 Expected results: javassist package from jbappplatform-6-server-6-rpm will be updated correctly Additional info:
Can you please try and install 'jbossas-javadocs' and see if the problem goes away? We may be able to add an Obsoletes in the EAP javassist-eap6 to prevent the old javassist to try and upgrade the OS one.
I installed jbossas-javadocs package before installing javasisst from eap chanell, but it didn't help.
The javassist-javadoc package from RHEL base, incorrectly, in my opinion, requires javassist. It should be possible to install the javadoc package without the main package, and thereby have the javassist-javadoc-3.9.0 and javassist-3.15.0 installed simultaneously, although I don't see why this is the intended case due to the difference in versions. I believe it is intentional in Fedora/RHEL for the javadoc package to require the main package with the jars, or else I would suggest filing a bug against that distribution instead.
The javassist-javadoc package being installed is the one from RHEL base. Moreover, the version is older than the javassist version in EAP, which shows that we do not ship a javassist-javadoc package. Neither our javassist package nor our javassist-eap6 package has a dependency on javassist-javadoc (perhaps the reporter meant that the other way around). Thus, this bug appears to detail an issue with the Fedora/RHEL package and not the package in EAP.
(In reply to Katerina Novotna from comment #2) > I installed jbossas-javadocs package before installing javasisst from eap > chanell, but it didn't help. I think he means that jbossas-javadocs should contain the javassist javadoc and that there is no separate javassist javadoc package.
Issue looks similar to the same situation from the past - httpd w/wo httpd-manual. Dependency from javassist-javadoc to javassist is correct from my PoV. Our jbossas-javadoc has the same dependency to jbossas... (or httpd-manual -> httpd etc.) The issue comes from the fact we don't ship javassist-javadoc in our channel at all. If we do that customer can upgrade to javassist from our channel whether he installed it from RHEL or not. So the fix could be - we should start ship javassist-javadoc - the same as we did in a quite recent history for httpd-manual which hadn't been shipped originally.
I can add an Obsoletes to javassist-eap6 for our version of javassist. This should block the javassist version in the eap channel thereby allowing the install of javassist from rhel-server-optional-6 to satisfy its dependency.
OK, the right fix would be to fix it in RHEL-6, but this can take a long time and as it is a small impact issue it may never make into a point release. So we are left with the Obsoletes but this may have implications for RHEV. I am starting a thread to make sure we can Obsolete the javassist-3.15.0-5.GA_redhat_2.ep6.el6.3.noarch package. In the meanwhile David has built javassist-eap6 with the Obsoletes and Andrew has confirmed it solves the issue described here.
Discussed with Ivo, flush it.
Verified with EAP-6.3.2.CP.CR2. If a customer follows supported (= documented) use-cases he can't get into the troubles. Older javassist in EAP channel is obsoleted (if installed already, it is correctly uninstalled during installation/update), moreover javaassist-eap6 doesn't interfere with javassist from BaseOS.