Bug 1111349

Hi!

I made some digging and could not reproduce. The ordewithrequres seems to did its hob properly.

interesting - i had the same messages for the last two updates

in both caaes java-1.7.0-openjdk and java-1.7.0-openjdk-headless downloaded from koji and update with "yum update *.rpm" from the download folder

Can you see the same behaviour when using yum?

how is "yum update *.rpm" not using yum?

Sorry. I said it wrongly.

I meant normal "yum updta "java-1.7.0-openjdk*""  without using the downlaoded files.

Well I doubt this is an case (as I have not reproduced it with files) but  I have run out of ideas what different  can be on your machine.

Adding lzachar to loop, as I'm aware he once had this issue.

there is no difference by feed yum with a downloaded package from a repo or a local file and until new builds are made it to updates-testing there is no way to call "yum update" without downloading the packages

the question is why it pretends files are not existing and needs to be remove

[root@srv-rhsoft:~]$ locate /jre/lib/amd64/libpulse-java.so
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre/lib/amd64/libpulse-java.so

and yes, this happens too on stable upgrades with no local download and happens due cleanup

warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/tapset/jstack-1.7.0.60-2.4.7.4.fc20.stp: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/tapset/hotspot_jni-1.7.0.60-2.4.7.4.fc20.stp: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/tapset/hotspot_gc-1.7.0.60-2.4.7.4.fc20.stp: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/tapset/hotspot-1.7.0.60-2.4.7.4.fc20.stp: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/tapset: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/tools.jar: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/sa-jdi.jar: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/orb.idl: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/jexec: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/jconsole.jar: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/ir.idl: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/dt.jar: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/ct.sym: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/amd64/jli/libjli.so: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/amd64/jli: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib/amd64: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/lib: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include/linux/jni_md.h: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include/linux/jawt_md.h: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include/linux: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include/jvmticmlr.h: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include/jvmti.h: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include/jni.h: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include/jdwpTransport.h: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include/jawt.h: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include/classfile_constants.h: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/include: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/xjc: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/wsimport: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/wsgen: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/unpack200: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/tnameserv: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/servertool: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/serialver: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/schemagen: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/rmiregistry: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/rmid: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/rmic: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/policytool: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/pack200: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/orbd: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/native2ascii: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/keytool: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jstatd: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jstat: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jstack: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jsadebugd: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jrunscript: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jps: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jmap: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jinfo: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jhat: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jdb: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jconsole: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jcmd: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/javap: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/javah: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/javadoc: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/javac: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/java-rmi.cgi: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/java: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jarsigner: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/jar: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/idlj: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/extcheck: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/apt: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin/appletviewer: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/bin: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/THIRD_PARTY_README: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/LICENSE: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/ASSEMBLY_EXCEPTION: remove failed: No such file or directory

* i removed both java-packages with rpm -e --nodeps
* installed both again with yum
* another rpm -e --nodpes still the same warnings

[root@srv-rhsoft:/lib/modules]$ rpm -e --nodeps java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64 java-1.7.0-openjdk-headless-1.7.0.60-2.5.0.1.fc20.x86_64
Warnung: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre/lib/amd64/xawt/libmawt.so: remove failed: Datei oder Verzeichnis nicht gefunden
Warnung: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre/lib/amd64/libsplashscreen.so: remove failed: Datei oder Verzeichnis nicht gefunden
Warnung: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre/lib/amd64/libpulse-java.so: remove failed: Datei oder Verzeichnis nicht gefunden
Warnung: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre/lib/amd64/libjsoundalsa.so: remove failed: Datei oder Verzeichnis nicht gefunden

*** Bug 1111846 has been marked as a duplicate of this bug. ***

*** Bug 1102978 has been marked as a duplicate of this bug. ***

*** Bug 1114122 has been marked as a duplicate of this bug. ***

Just headup. I have just  I hit this with future update:-/

cool :-)

i hit it with every update

I think the reason as to why this is happening is because because java-1.7.0-openjdk-headless which owns the top-level JDK directory gets removed too early. Why? Because there is no hard dependency between certain sub-packages and *-headless. For example *-devel puts files under the main JDK directory, but does not have "Requires: java-1.7.0-openjdk-headless". Thus, if one upgrades, say *-devel and *-headless, via yum, yum is allowed to remove *-headless before *-devel. Since *-headless removes the entire top-level JDK directory no files are left for the *-devel package to remove.

I wonder why *-headless owns the entire directory recursively. Perhaps it's missing "%dir" for %{_jvmdir} ?

If I do "rpm -e --nodeps java-1.7.0-openjdk-headless" it indeed removes all files under /usr/lib/jvm/java-1.7.0-openjdk-<version>.fc20.x86_64

As far as warnings in comment 0 are concerned I'm not sure how to reproduce this. The java-1.7.0-openjdk package has a dependency on java-1.7.0-openjdk-headless. Thus on clean-up it should really clean-up java-1.7.0-openjdk then java-1.7.0-openjdk-headless, in that order. rpm -e --nodeps probably disregards deps (you told it to) so that command removing packages in the wrong order is somewhat explainable.

I don't think OrderWithRequires is the right solution, Jiri. According to[1] it's really only a trick for yum group-installs where packages have no dependency on each other. Perhaps this OrderWithRequires is confusing rpm. Not sure.

I've produced a scratch build which should have RPMs which should not have the issue. Note: It will take at least two update cycles with both having the fix in order for this issue to be gone entirely:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7124340

I'm attaching a patch with the proposed solution. Let me know what you think.

[1] http://www.spinics.net/lists/rpm/msg07594.html

Created attachment 917099 [details]
Proposed fix for F20 spec.

The fix have worked for you?

The reason why they do not have Requires: *headles is, that they Requires jre, which requires jre headless. So it is Transitive dependence, and should not be affected by your fix.

and why can't it require 'headless' which is the core component of openjdk?

(In reply to jiri vanek from comment #16)
> The fix have worked for you?

I thought it has. Thinking more about it, it's probably something else. That's why I dug deeper.

> The reason why they do not have Requires: *headles is, that they Requires
> jre, which requires jre headless. So it is Transitive dependence, and should
> not be affected by your fix.

It worked for me in such a way that headless gets removed last on upgrades. At least I think it did. But I get your point. By the transitive dep chain it should have the same effect.

OK, so here is a problem which is easy to reproduce:

$ rpm -qa | grep java-1.7.0-openjdk-devel
java-1.7.0-openjdk-devel-1.7.0.65-2.5.1.2.fc20.x86_64
$ sudo rpm -e --nodeps java-1.7.0-openjdk-headless
$ rpm -V java-1.7.0-openjdk-devel
missing   d /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/ASSEMBLY_EXCEPTION
missing   d /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/LICENSE
missing   d /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/THIRD_PARTY_README
<many-more>

OK, reinstalled -headless and did this:

$ sudo rpm -e -vvv --nodeps java-1.7.0-openjdk-headless
[...]
D: %postun(java-1.7.0-openjdk-headless-1:1.7.0.65-2.5.1.2.fc20.x86_64): execv(/bin/sh) pid 17074
+ alternatives --remove java /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/jre/bin/java
+ alternatives --remove jre_openjdk /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/jre
+ alternatives --remove jre_1.7.0 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/jre
+ alternatives --remove jre_1.7.0_openjdk /usr/lib/jvm/jre-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64
+ '[' -e /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64 ']'
+ rm -rf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64
+ exit 0
[...]

Then looking at the spec I see this indeed:
%postun headless
  alternatives --remove java %{jrebindir}/java
  alternatives --remove jre_%{origin} %{_jvmdir}/%{jredir}
  alternatives --remove jre_%{javaver} %{_jvmdir}/%{jredir}
  alternatives --remove jre_%{javaver}_%{origin} %{_jvmdir}/%{jrelnk}

  # avoid unnecessary failure
  if [ -e %{_jvmdir}/%{uniquesuffix} ]  ; then
    # as lua copied all necessary config files, we do not wont the double rpmnew and rpm.save
    rm -rf %{_jvmdir}/%{uniquesuffix}
  fi
exit 0

So my take is that this 'rm -rf %{_jvmdir}/%{uniquesuffix}' screws things up badly.

One more thing. The following files are listed in headless *and* devel:
%doc %{_jvmdir}/%{sdkdir}/ASSEMBLY_EXCEPTION
%doc %{_jvmdir}/%{sdkdir}/LICENSE
%doc %{_jvmdir}/%{sdkdir}/THIRD_PARTY_README
%{jvmjardir} (as %{_jvmjardir}/%{sdkdir} in -devel)

Is there a reason why both packages own these?

(In reply to Harald Reindl from comment #17)
> and why can't it require 'headless' which is the core component of openjdk?

-headless is less than the main java-1.7.0-openjdk. It does not include alsa sound and some other libs. It does make sense for demo, devel, etc. to depend on the full JRE. The idea of -headless was to have something for java libs to depend on which drags in less of X/sound as the full JRE would do.

i know that *but* why can't 'java-1.7.0-openjdk' require 'java-1.7.0-openjdk-headless' - it needs it anyways - the other direction is optional

(In reply to Harald Reindl from comment #20)
> i know that *but* why can't 'java-1.7.0-openjdk' require
> 'java-1.7.0-openjdk-headless' - it needs it anyways - the other direction is
> optional

It does that already:
$ rpm -q --requires java-1.7.0-openjdk | grep java-1.7.0-openjdk
java-1.7.0-openjdk-headless = 1:1.7.0.65-2.5.1.2.fc20

Sorry I didn't mean to confuse people with my proposed patch in comment 15. Please ignore that patch.

Hmm... After few more investigations here I came to conclusion that this is not bug in JDK packages, but bug in RPM. Openjdk packages are making this (because of quite ...not standard behaviour)  bug visible.

The OrderWithRequire, which was about to fix previous issues of similar (much more terrible)  issues.. Really did.  But there are cases when OrderWithRequires donot help. Clear proof is this log:

Running transaction
  Updating   : 1:java-1.7.0-openjdk-headless-1.7.0.65-2.5.1.2.el7_0.x86_64
warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64/jre/lib/security/US_export_policy.jar created as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64/jre/lib/security/US_export_policy.jar.rpmnew
warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64/jre/lib/security/local_policy.jar created as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64/jre/lib/security/local_policy.jar.rpmnew
  Updating   : 1:java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64
  Updating   : 1:java-1.7.0-openjdk-devel-1.7.0.65-2.5.1.2.el7_0.x86_64
  Updating   : 1:java-1.7.0-openjdk-src-1.7.0.65-2.5.1.2.el7_0.x86_64
  Updating   : 1:java-1.7.0-openjdk-javadoc-1.7.0.65-2.5.1.2.el7_0.noarch
  Cleanup    : 1:java-1.7.0-openjdk-src-1.7.0.55-2.4.7.2.el7_0.x86_64
  Cleanup    : 1:java-1.7.0-openjdk-javadoc-1.7.0.55-2.4.7.2.el7_0.noarch
  Cleanup    : 1:java-1.7.0-openjdk-devel-1.7.0.55-2.4.7.2.el7_0.x86_64
  Cleanup    : 1:java-1.7.0-openjdk-headless-1.7.0.55-2.4.7.2.el7_0.x86_64
  Cleanup    : 1:java-1.7.0-openjdk-1.7.0.55-2.4.7.2.el7_0.x86_64
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.55-2.4.7.2.el7_0.x86_64/jre/lib/amd64/xawt/libmawt.so: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.55-2.4.7.2.el7_0.x86_64/jre/lib/amd64/libsplashscreen.so: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.55-2.4.7.2.el7_0.x86_64/jre/lib/amd64/libpulse-java.so: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.55-2.4.7.2.el7_0.x86_64/jre/lib/amd64/libjsoundalsa.so: remove failed: No such file or directory
  Verifying  : 1:java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64
  Verifying  : 1:java-1.7.0-openjdk-javadoc-1.7.0.65-2.5.1.2.el7_0.noarch
  Verifying  : 1:java-1.7.0-openjdk-headless-1.7.0.65-2.5.1.2.el7_0.x86_64
  Verifying  : 1:java-1.7.0-openjdk-devel-1.7.0.65-2.5.1.2.el7_0.x86_64
  Verifying  : 1:java-1.7.0-openjdk-src-1.7.0.65-2.5.1.2.el7_0.x86_64
  Verifying  : 1:java-1.7.0-openjdk-headless-1.7.0.55-2.4.7.2.el7_0.x86_64
  Verifying  : 1:java-1.7.0-openjdk-devel-1.7.0.55-2.4.7.2.el7_0.x86_64
  Verifying  : 1:java-1.7.0-openjdk-src-1.7.0.55-2.4.7.2.el7_0.x86_64
  Verifying  : 1:java-1.7.0-openjdk-javadoc-1.7.0.55-2.4.7.2.el7_0.noarch
  Verifying  : 1:java-1.7.0-openjdk-1.7.0.55-2.4.7.2.el7_0.x86_64

The update[1] is honouring the OrderWithRequires specified  in spec, however *cleanup* is *not* [2]

[1]
  Updating   : 1:java-1.7.0-openjdk-headless-1.7.0.65-2.5.1.2.el7_0.x86_64
  Updating   : 1:java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64
  Updating   : 1:java-1.7.0-openjdk-devel-1.7.0.65-2.5.1.2.el7_0.x86_64
  Updating   : 1:java-1.7.0-openjdk-src-1.7.0.65-2.5.1.2.el7_0.x86_64
  Updating   : 1:java-1.7.0-openjdk-javadoc-1.7.0.65-2.5.1.2.el7_0.noarch
[2]
  Cleanup    : 1:java-1.7.0-openjdk-src-1.7.0.55-2.4.7.2.el7_0.x86_64
  Cleanup    : 1:java-1.7.0-openjdk-javadoc-1.7.0.55-2.4.7.2.el7_0.noarch
  Cleanup    : 1:java-1.7.0-openjdk-devel-1.7.0.55-2.4.7.2.el7_0.x86_64
  Cleanup    : 1:java-1.7.0-openjdk-headless-1.7.0.55-2.4.7.2.el7_0.x86_64
  Cleanup    : 1:java-1.7.0-openjdk-1.7.0.55-2.4.7.2.el7_0.x86_64


expected result (of [2])

  Cleanup    : 1:java-1.7.0-openjdk-src-1.7.0.55-2.4.7.2.el7_0.x86_64
  Cleanup    : 1:java-1.7.0-openjdk-javadoc-1.7.0.55-2.4.7.2.el7_0.noarch
  Cleanup    : 1:java-1.7.0-openjdk-devel-1.7.0.55-2.4.7.2.el7_0.x86_64
  Cleanup    : 1:java-1.7.0-openjdk-1.7.0.55-2.4.7.2.el7_0.x86_64
  Cleanup    : 1:java-1.7.0-openjdk-headless-1.7.0.55-2.4.7.2.el7_0.x86_64

Reasssigning to RPM

> Small replyto comment c#6
> there is no difference by feed yum with a downloaded package from a repo or a local file and until new builds are made it to updates-testing there is no way to call "yum update" without downloading the packages
>


I had an suspicion, that rpm canbe forced to use wrong order, by plain putting of the rpm files onto commandline of rpm in wrong order (and so keep yum to handle the order). But apparently I was wrong, as above can be reproduced both by rpm and yum.

My very own opinion about this is as follows. I think that the openjdk packaging should be rethought in general. From what I see within my filesystem - and as a java developer (more or less) myself - the openjdk installation looks quite messy to me. There are plenty of symlinks that links from A to B. My Fedora 20 installation comes with an /usr/lib/java-1.4 till java-1.8 directory structure. There are also these jvm-* directories. Inside these directories there are symlinks to other places as well. Comparing to the Windows installation of openjdk it only requires 1-2 directories inside program files and a bunch of registry entries. Since Fedora 16 I always asked myself "how on earth does this work - and for how long".

Just my thoughts.

/usr/lib/java-1.* those directories have nothing to do with jdk. Ask java-maint (users of jdk) why they are still there.


Jdk is stored in only one directory - /usr/lib/jvm/java-1.X.Y-openjdk.fullVersionWithArch


The versionless symlinks are necessary - without them you will not be able to use jdk without knowing full path, which is really uncomfortable. Also the alternatives are working really really well. You can change your jre/jdk by two comamnds.

Also the manpages are where they belongs.

Also recently intorduced multiple-jdk feature is quite a good one and is serving JDK engineers very well. 

Thats for positives.

Otherwise I agree with you on rest:
The jvm-exports directory or several jre/sdk_dir/exports alternative keys... Well tbh I doubt about them . I have no idea why they were introdced (yah, they are really old) But I'm afraid once those are removed, a lot of (Imean to much to just say "fix it on ou rown)  will get angry. 

But definitely this is for different bug then this one.

The decisions we made a very long time ago based on the requirements that multiple jdk's with different major versions from multiple vendors all be installable and useable in parallel.

The idea is to provide maximum flexibility not only for installation but also for packages that utilize these JVMs.

Listed below are the alternatives on my F20 system (1.5/1.6 ones are redacted) and what they mean. Please let me know if I missed anything else that is unclear.

==

Misc. java related binary links: Links to individual binaries for the system selected JRE/JDK alternative

java_sdk: This link for applications that want to strictly use the system selected JDK alternative.

java_sdk_exports: Directory containing JDK provided .jar files (analogous to /usr/share/java but for system selected alternative).

java_sdk_1.7.0: This link is for applications that want JDK7 (JRE7 + dev) but do not care about vendor (i.e. use alternative selected vendor).

java_sdk_1.7.0_exports: Directory containing JDK7 provided .jar files (analogous to /usr/share/java but for a JDK7).

java_sdk_1.7.0_openjdk: This link is for applications that do not care about what the system alternative is, and instead, what to specifically use JDK7 from OpenJDK.

java_sdk_1.7.0_openjdk_exports: Directory containing OpenJDK7 provided .jar files (analogous to /usr/share/java but for OpenJDK7).

java_sdk_openjdk: This link is for applications that do not care about JDK version but want to use OpenJDK specifically.

java_sdk_openjdk_exports:Directory containing JDK provided .jar files (analogous to /usr/share/java but for any "JDK").

jre: This link for applications that want to strictly use the system selected JRE alternative.

jre_exports: Directory containing JRE provided .jar files (analogous to /usr/share/java but for system selected alternative).

jre_1.7.0: This link is for applications that do not care about vendor, but specifically want JRE 1.7 (i.e. runtime only) selected by alternatives.

jre_1.7.0_exports:Directory containing JRE7 provided .jar files (analogous to /usr/share/java but for a JRE7).

jre_1.7.0_openjdk: This link is for applications that specifically want JRE 1.7 from OpenJDK.

jre_1.7.0_openjdk_exports: Directory containing OpenJDK JRE7 provided .jar files (analogous to /usr/share/java but for OpenJDK JRE7).

jre_openjdk: This link for applications that specifically want the JRE from OpenJDK, but do not care about version.

jre_openjdk_exports: Directory containing JRE provided .jar files (analogous to /usr/share/java but for any "JRE").

==

As you can see above, each link serves to satisfy different needs. These different needs are quite applicable in real world usage scenarios. Sometimes they are applicable for the application developer (e.g. "I have only designed and tested my package with JDK XYZ so I want it to run with only that") and at other times they are applicable for end-users (e.g "I have a support contract with vendor XYZ, I want  application ABC to run with that specific vendor's JDK").

Jiri, what's the operation you've been running for #22 ?

Can you make sure that there is no dependency loop involved here - neither via Requires nor via OrderBYRequires (or both), please?

Thanx, Florian

(In reply to Florian Festi from comment #26)
> Jiri, what's the operation you've been running for #22 ?

sudo yum update java-1.7.0-openjdk*
or
sudo yum install  list_individual_rpms_here

but also rpm -u have the symtomps. 

> Can you make sure that there is no dependency loop involved here - neither
> via Requires nor via OrderBYRequires (or both), please?
> 

I was trying to find something like that, but have not. IS there some check I should provide?

There are three dependency loops in this transaction. The first is java-1.7.0-openjdk requires java-1.7.0-openjdk-headless which requires java-1.7.0-openjdk:

$ rpm -q --requires java-1.7.0-openjdk
...
java-1.7.0-openjdk-headless = 1:1.7.0.65-2.5.1.2.fc20
...

$ rpm -q --requires java-1.7.0-openjdk-headless
...
libmawt.so()(64bit)
...
$ rpm -q --provides java-1.7.0-openjdk
...
libmawt.so()(64bit)
...

The other dependency loops are:
java-1.7.0-openjdk-devel => java-1.7.0-openjdk-headless => (libjli.so()(64bit))java-1.7.0-openjdk-devel
java-1.7.0-openjdk => java-1.7.0-openjdk-headless => (libjli.so()(64bit))java-1.7.0-openjdk-devel => java-1.7.0-openjdk

I'm still not sure if this is bug in JRE

Yes, those loops exists. However, they are not true loops:

Issues are:
that both jre and jre-headles both provides and  both requires libmawt.so
However, this is not same library.
the first is located  in 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.../jre/lib/amd64/xawt
and second
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.../jre/lib/amd64/headless

And those libraries are *not* same. Actually they differ crucially.


The jli is similar, but opposite to above can be changed.
Currently, both jre-headless and devel contains 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.../jre/lib/amd64/jli/libjli.so
THis was chosen long ago... An dI think we can happily live with jli  in headless only.


Florian cant the strange libmawt be the cause of incorrect behaviour in rpm?

Thanks, Kardos, I misssed that one.

Ok, the problem here is even a bit more complicated.

Yes, libmawt is the reason for the problem here. Who's exactly to blame is an interesting question. Having two libraries with the same name but with different content is surely not helping.

On could argue that rpm

a) should detect that java-1.7.0-openjdk-headless is providing libmawt.so()(64bit) on it's own and not generate any relations to other packages for this requirement
b) or even should be more precise during ordering and require just one provider to be installed first and not all of them.

Changing any of the the three above will make this problem go away. a) is something that could be done with relatively small effort. b) requires rewriting the ordering code (Not again!). No idea how easy or complicated it is to entangle the libs in the java-1.7.0-openjdk (sub) packages...

Oh, just for the record:

This is completely unrelated to OrderByRequires other than that they are used exactly the same way as normal Requires during ordering - for both installs and erases.

Thank you for confirmation. 

I have no idea how to solve libmawt issue without huge fixing in jdk build code (and I dont know it it is even really possible...)

If (a) is possible, and sounds as reasonable one - is it worthy to try?

If so, feel free to switch component back to rpm.

I don't really understand much of this discussion, but isn't there a way to override the automagic provides and requires stuff in the spec file? Possibly you could make it believe there were different libmawt files with different provides names?

As I have jsut learned,  it should be possible by %global __requires_exclude regex

http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering


So I guess its better to do so, rather then requiring fix in RPM which maybe is not fixing a bug.

Again, Florian, how do you feal about it?

That's probably the best solution for the package right now. I already have some code that filters out self provides during the ordering process but that needs some more testing and you probably do not want to wait until it lands in Fedora - if it makes it into F20 at all.

I would suggest you filter out the Requires: and close this bug.

pushed to fedora. Lets see the results :)

http://pkgs.fedoraproject.org/cgit/java-1.7.0-openjdk.git/commit/java-1.7.0-openjdk.spec?h=f20&id=2ec1bfa6f866e194b3ddf97ca45f8ebcd5501ed4

Thanx everybody for coopeartion.

at least the "yum update *.rpm" with the koji build worked without that warnings

Jul 22 15:32:49 Updated: 1:java-1.7.0-openjdk-headless-1.7.0.65-2.5.1.4.fc20.x86_64
Jul 22 15:32:49 Updated: 1:java-1.7.0-openjdk-1.7.0.65-2.5.1.4.fc20.x86_64

Thank you for confirmation!

Hello Everyone,
Warning still exist 



  Cleanup    : 1:java-1.7.0-openjdk-headless-1.7.0.65-2.5.1.2.fc20.x86_64                                                      232/279 
  Cleanup    : 1:java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64                                                               233/279 
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/jre/lib/amd64/xawt/libmawt.so: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/jre/lib/amd64/libsplashscreen.so: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/jre/lib/amd64/libpulse-java.so: remove failed: No such file or directory
warning: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc20.x86_64/jre/lib/amd64/libjsoundalsa.so: remove failed: No such file or directory

Ok. So it seems it was finally fixed.

Your next udpate will be still spawning warnings, but update of this update will be hopefully silent.

(https://admin.fedoraproject.org/updates/java-1.8.0-openjdk-1.8.0.60-11.b24.fc23 - but note - although this build (and similar for f21/f211 is fixing it. Update of *this* package will be silent.