From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 Description of problem: The update from mx4j broke tomcat v4.1.27 as supplied by jpackage, causing a major outage on a production system. Even though JPP is an external project to Redhat, the Redhat packages still need to "play nice", otherwise decisionmakers will lose faith in up2date on live systems, and we're back to security hole hell. The fix is to revert back to the JPP provided RPM of mx4j. Version-Release number of selected component (if applicable): mx4j-1.1.1-6 How reproducible: Always Steps to Reproduce: xxx Additional info:
Only Red Hat signed packages are supported on RHEL3 systems. Tomcat (5 only) support will be provided as part of out RHAPS (Application Server) offering. Tomcat 4 was in the Beta (unsupported) version of RHAPS. If you think Tomcat4 should still be supported please tell your representative so he/she can pass this request to Marketing. Ask you sales representative about RHAPS.
The problem was not whether something was supported or not, but whether Redhat were responsible enough during software releases to ensure their releases "played nice" with others in the marketplace. If it turns out that automatic updates break production systems, then we will abandon the use of automatic updates on our systems, and in turn probably abandon the RHEL distribution for a vendor that takes software releases more seriously. If Redhat's approach to this issue is to just refer the customer to marketing, then we will be considering a competing product in future.
How did it break it exactly? Did the JPackage mx4j get overwritten?
Redhat released mx4j-1.1.1-6, which is technically later than JPP's most recent release mx4j-1.1.1-5jpp. The JPP release of tomcat does not detect the jar files from mx4j-1.1.1-6, which caused it to fail to start on its next invocation after the update.