Bug 1111349 - broken files
broken files
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: java-1.8.0-openjdk (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: jiri vanek
Fedora Extras Quality Assurance
:
: 1102978 1111846 1114122 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-06-19 15:56 EDT by Harald Reindl
Modified: 2015-08-14 07:06 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-22 06:23:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed fix for F20 spec. (3.55 KB, patch)
2014-07-10 09:59 EDT, Severin Gehwolf
no flags Details | Diff

  None (edit)
Description Harald Reindl 2014-06-19 15:56:56 EDT
while all seems to work due update to the latest koji build as well as the one yesterday there are warnings about remove files failed and alternatives seems also not be too happy

java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64.rpm
java-1.7.0-openjdk-headless-1.7.0.60-2.5.0.1.fc20.x86_64.rpm
_______________________________________________

at update:
Warnung: file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.0.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.0.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.0.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.0.fc20.x86_64/jre/lib/amd64/libjsoundalsa.so: remove failed: Datei oder Verzeichnis nicht gefunden

alternatives --list  | grep java:
failed to read link /usr/share/java/jaxp_parser_impl.jar: No such file or directory
Comment 1 jiri vanek 2014-06-23 05:45:20 EDT
Hi!

I made some digging and could not reproduce. The ordewithrequres seems to did its hob properly.
Comment 2 Harald Reindl 2014-06-23 05:55:20 EDT
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
Comment 3 jiri vanek 2014-06-25 03:58:09 EDT
Can you see the same behaviour when using yum?
Comment 4 Harald Reindl 2014-06-25 06:41:21 EDT
how is "yum update *.rpm" not using yum?
Comment 5 jiri vanek 2014-06-25 09:15:15 EDT
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.
Comment 6 Harald Reindl 2014-06-25 16:33:53 EDT
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
Comment 7 Harald Reindl 2014-06-26 08:16:15 EDT
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
Comment 8 Harald Reindl 2014-06-27 21:01:11 EDT
* 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
Comment 9 jiri vanek 2014-06-30 05:35:51 EDT
*** Bug 1111846 has been marked as a duplicate of this bug. ***
Comment 10 jiri vanek 2014-06-30 05:36:28 EDT
*** Bug 1102978 has been marked as a duplicate of this bug. ***
Comment 11 jiri vanek 2014-06-30 05:40:16 EDT
*** Bug 1114122 has been marked as a duplicate of this bug. ***
Comment 12 jiri vanek 2014-07-03 09:03:46 EDT
Just headup. I have just  I hit this with future update:-/
Comment 13 Harald Reindl 2014-07-03 09:13:42 EDT
cool :-)

i hit it with every update
Comment 14 Severin Gehwolf 2014-07-10 09:55:52 EDT
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
Comment 15 Severin Gehwolf 2014-07-10 09:59:17 EDT
Created attachment 917099 [details]
Proposed fix for F20 spec.
Comment 16 jiri vanek 2014-07-14 08:27:33 EDT
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.
Comment 17 Harald Reindl 2014-07-14 11:02:23 EDT
and why can't it require 'headless' which is the core component of openjdk?
Comment 18 Severin Gehwolf 2014-07-16 07:29:25 EDT
(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?
Comment 19 Severin Gehwolf 2014-07-16 07:32:55 EDT
(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.
Comment 20 Harald Reindl 2014-07-16 07:55:02 EDT
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
Comment 21 Severin Gehwolf 2014-07-16 08:50:50 EDT
(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.
Comment 22 jiri vanek 2014-07-17 07:59:47 EDT
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.
Comment 23 Ali Akcaagac 2014-07-17 17:38:16 EDT
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.
Comment 24 jiri vanek 2014-07-18 04:07:27 EDT
/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.
Comment 25 Deepak Bhole 2014-07-18 15:16:53 EDT
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").
Comment 26 Florian Festi 2014-07-21 04:57:33 EDT
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
Comment 27 jiri vanek 2014-07-21 06:11:28 EDT
(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?
Comment 28 Ľuboš Kardoš 2014-07-21 06:14:19 EDT
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
Comment 29 jiri vanek 2014-07-21 06:59:43 EDT
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?
Comment 30 Florian Festi 2014-07-21 07:25:59 EDT
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...
Comment 31 Florian Festi 2014-07-21 07:28:11 EDT
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.
Comment 32 jiri vanek 2014-07-21 07:43:10 EDT
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.
Comment 33 Tom Horsley 2014-07-21 08:17:52 EDT
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?
Comment 34 jiri vanek 2014-07-21 09:41:29 EDT
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?
Comment 35 Florian Festi 2014-07-21 12:12:02 EDT
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.
Comment 36 jiri vanek 2014-07-22 06:23:43 EDT
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.
Comment 37 Harald Reindl 2014-07-22 09:39:41 EDT
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
Comment 38 jiri vanek 2014-07-22 10:52:53 EDT
Thank you for confirmation!
Comment 39 Slava 2014-08-01 22:22:13 EDT
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
Comment 40 jiri vanek 2015-08-14 07:05:06 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.