Bug 156038

Summary: [relnote?] A yum upgrade can install an incompatible "newer" version of jpackage-utils which breaks fedora package scriptlet(s)
Product: [Fedora] Fedora Reporter: Robin Green <greenrd>
Component: jpackage-utilsAssignee: Thomas Fitzsimmons <fitzsim>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: arequipeno, fnasser, mefoster, nicolas.mailhot, tromey
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: 2005-04-27 18:45:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robin Green 2005-04-26 20:38:11 UTC
Description of problem:
I have a jpackage yum repository in my /etc/yum.repos.d (yum or apt are the
recommended ways to install packages for jpackage, so this applies to lots of
people). Unfortunately the latest jpackage-utils shipped by jpackage.org is
slightly incompatible with rawhide - it doesn't have the
rebuild-security-providers command, so java-1.4.2-gcj-compat fails to upgrade,
install OR erase(!) - unless you use the --noscripts flag, which is not really
desirable. (There might be other incompatibilities too, I don't know.)

Three suggested options to address this:

1. Politely ask jpackage.org to make changes to make theirs compatible (I'm
CC'ing selected jpackage packagers to this bug)

2. Or, ship an /etc/yum.repos.d/jpackage.repo in fedora, containing:

[jpackage]
name=JPackage 1.6
baseurl=http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/jpackage/1.6/generic/free/
gpgcheck=1
exclude=jpackage-utils

- and any other excludes that may become necessary to solve compatibility
problems that may arise. And a corresponding jpackage-fedora.repo file (that's
the jpackage.org-managed repo that contains platform-specific RPMs for fedora.)
Unfortunately this has two problems: (a) Red Hat legal might not like it,
especially so close to a Fedora release with little time to decide, (b) it might
give rise to flames about perceived "favouritism" towards one third-party
repository on the part of the Fedora project.

3. Or, just note the problem in the release notes.

Version-Release number of selected component (if applicable):
Fedora version: jpackage-utils-1.6.2-1jpp_6rh
JPackage version: jpackage-utils-1.6.3-1jpp

How reproducible:
Always

Steps to Reproduce:
1. Add jpackage repo (without the exclude line given above) to yum configuration
2. yum upgrade jpackage-utils
3. rpm -e java-1.4.2-gcj-compat
  
Actual results:
/var/tmp/rpm-tmp.69465: line 7: rebuild-security-providers: command not found
error: %postun(java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh.i386) scriptlet failed,
exit status 127


Expected results:
No error

Comment 1 Ian Pilcher 2005-04-27 14:44:20 UTC
A fourth option, separate the Fedora Core Java stuff into its own "channel".

Comment 2 Fernando Nasser 2005-04-27 15:06:30 UTC
Please not that we have far from the complete set of Java packages offered by
JPackage.org and people are bound to install (using yum) more things from the
JPackage repository.  So they will eventually add the JPackage repository back
in the yum configuration.

JPackage seem to be willing to find a way to make the upstream version
compatible.  It is just a question of someone proposing a patch to the upstream
jpackage-utils.  One could possibly start by looking into the changes that broke
compatibility.

Comment 3 Thomas Fitzsimmons 2005-04-27 17:04:31 UTC
All I need to do to solve this is import jpackage-utils-1.6.3 into Fedora.  I'll
do that today.


Comment 4 Thomas Fitzsimmons 2005-04-27 18:45:53 UTC
Done.  Closing.


Comment 5 Mary Ellen Foster 2005-11-03 09:56:35 UTC
This is broken again, as far as I can tell; I've currently got
jpackage-utils-1.6.6-1jpp installed, and I'm getting the same symptoms. It would
be great if this change actually got imported into the upstream package so it
stays current when that updates.