From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-2
Description of problem:
The ant rpm lacks appropriate dependencies for it's %post/%postun scripts
This prevents proper deinstallation of the ant-rpm with yum.
It should use.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum install ant libgcj
2. yum remove libgcj
# yum remove libgcj
---> Package ant.i386 0:1.6.2-3jpp_8fc set to be erased
Removing : ant ####################### [ 5/10]
/var/tmp/rpm-tmp.38341: line 1: /usr/bin/rebuild-gcj-db: No such file or directory
error: %postun(ant-1.6.2-3jpp_8fc.i386) scriptlet failed, exit status 127
# rpm -q ant
Expected Results: Clean removal of ant
%postun scripts crashing cause yum to enter situations it can't handle and can cause further installation problems:
E.g. after the yum remove ant above:
# yum update
No Packages marked for Update/Obsoletion
For comparison: apt-get finds these rpm inconsistencies:
# apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
You might want to run `apt-get --fix-broken install' to correct these.
The following packages have unmet dependencies:
ant: Depends: java-devel
Depends: jpackage-utils (>= 0:1.5) but it is not installed
As far as I can see, ant.spec already contains the following
Requires(post,postun): java-1.4.2-gcj-compat >= 18.104.22.168-40jpp_16rh
And the java-1.4.2-gcj-compat package ships /usr/bin/rebuild-gcj-db.
So, the problem here is not that the depedency is left unspecified but
rather that rpm does not seem to be honoring it.
I think the workaround suggested by releng is to split the above into
two separate lines, like so:
Requires(post): java-1.4.2-gcj-compat >= 22.214.171.124-40jpp_16rh
Requires(postun): java-1.4.2-gcj-compat >= 126.96.36.199-40jpp_16rh
Gary, is that correct?
(In reply to comment #1)
> As far as I can see, ant.spec already contains the following
> Requires(post,postun): java-1.4.2-gcj-compat >= 188.8.131.52-40jpp_16rh
> And the java-1.4.2-gcj-compat package ships /usr/bin/rebuild-gcj-db.
> So, the problem here is not that the depedency is left unspecified but
> rather that rpm does not seem to be honoring it.
> I think the workaround suggested by releng is to split the above into
> two separate lines, like so:
> Requires(post): java-1.4.2-gcj-compat >= 184.108.40.206-40jpp_16rh
> Requires(postun): java-1.4.2-gcj-compat >= 220.127.116.11-40jpp_16rh
You could be right. AFAICT (and according to FE packaging guidelines), rpm still
doesn't honors Requires(post,postun) correctly.
Besides this, using file deps instead of package deps would be more
maintainable, because it would avoid problems should rebuild-gcj-db ever be
moved to a different package.
BTW: Many other java packages in FC4 suffer from the same issue.
Just try "yum install eclipse ; yum remove libgcj" - I see half a dozen of other
packages bombing out with similar warnings.
Unfortunatly file deps don't allow us to specify versions, which are (or will
very soon become) necessary.
Are you trying to say /usr/bin/rebuild-gcj-db's UI (options, args) is going to
Sorry, but this would be a severe design bug, and would block any rpm update
path, because you already are using /usr/bin/rebuild-gcj-db in %post/%postun
scripts, therefore *all* future versions of rebuild-gcj-db must be backward
compatible to *all* former versions having ever been shipped with RH/FC.
If you can't avoid changing it, you will have to ship versioned binaries or have
to install rebuild-gcj-db to different directories.
Yes, rebuild-gcj-db's UI is going to be changed.
No, this will not affect existing packages.
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present. Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.
Setting status to "INSUFFICIENT_DATA". If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested,
please feel free to reopen the bug report.
Thank you in advance.