+++ This bug was initially created as a clone of Bug #1200302 +++ Description of problem: As a side effect of other problems with dnf I had to reinstall few packages. After this action I was not able to use java related applications (e.g. eclipse) It took me few hours to find a root of all evil. dnf reinstall broke my alternatives and therefore java was removed from alternatives. Version-Release number of selected component (if applicable): sh$ rpm -q python3-dnf dnf python3-dnf-0.6.4-2.fc22.noarch dnf-0.6.4-2.fc22.noarch How reproducible: Deterministic Steps to Reproduce: 1. dnf-3 install java-1.8.0-openjdk-headless 3. dnf-3 reinstall java-1.8.0-openjdk-headless Actual results: [root@host ~]# java -version -bash: java: command not found [root@host ~]# update-alternatives --display java [root@host ~]# echo $? 2 Expected results: [root@host ~]# java -version openjdk version "1.8.0_40" OpenJDK Runtime Environment (build 1.8.0_40-b12) OpenJDK 64-Bit Server VM (build 25.40-b16, mixed mode) [root@host ~]# update-alternatives --display java java - status is auto. link currently points to /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/java /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/java - priority 1800040 slave jre: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre slave jre_exports: /usr/lib/jvm-exports/jre-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64 slave jjs: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/jjs slave keytool: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/keytool slave orbd: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/orbd slave pack200: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/pack200 slave rmid: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/rmid slave rmiregistry: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/rmiregistry slave servertool: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/servertool slave tnameserv: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/tnameserv slave unpack200: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/unpack200 slave java.1.gz: /usr/share/man/man1/java-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz slave jjs.1.gz: /usr/share/man/man1/jjs-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz slave policytool: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/policytool slave keytool.1.gz: /usr/share/man/man1/keytool-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz slave orbd.1.gz: /usr/share/man/man1/orbd-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz slave pack200.1.gz: /usr/share/man/man1/pack200-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz slave rmid.1.gz: /usr/share/man/man1/rmid-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz slave rmiregistry.1.gz: /usr/share/man/man1/rmiregistry-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz slave servertool.1.gz: /usr/share/man/man1/servertool-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz slave tnameserv.1.gz: /usr/share/man/man1/tnameserv-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz slave unpack200.1.gz: /usr/share/man/man1/unpack200-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz Current `best' version is /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/java Additional info: A workaroud for this bug is to reinstall package with yum. --- Additional comment from Jan Silhan on 2015-03-24 07:14:21 EDT --- Thanks for the report. Probably wrong scriplets. DNF uses the `ts.addReinstall` rpm method in contrast to yum. --- Additional comment from Lukas Slebodnik on 2015-03-24 07:23:07 EDT --- Thank you for info. If the bug is not in dnf then please reassign to correct component java-1.8.0-openjdk-headless or provide fix to java spec files. I don't mind where it will be fixed. --- Additional comment from Lukas Slebodnik on 2015-05-04 17:27:59 EDT --- dnf-yum redirected yum to dnf. As I mentions in the description of bug, it works with yum(yum-depreceated) but not with dnf. It would be good to either fix it in dnf or fix java packaging. Is there any progress with this BZ? --- Additional comment from Fedora Blocker Bugs Application on 2015-05-08 07:55:08 EDT --- Proposed as a Blocker for 22-final by Fedora user lslebodn using the blocker tracking app because: /usr/bin/yum is part of dnf-yum and it calls dnf under hood. Re-installation of java package causes dis-functional java and many popular IDEs will not start. It works with yum (yum-deprecated) so it is a regression caused by dnf-yum. --- Additional comment from Dan Mossor [danofsatx] on 2015-05-11 15:28:23 EDT --- Discussed at the 2015-05-11 blocker review meeting[0]. Voted as RejectedBlocker. #agreed 1200302 - RejectedBlocker - this bug obviously sucks if you run into it, but doesn't seem especially critical to the release media, doesn't violate any release criteria, and seems unlikely to be hit very often [0]: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-11/ --- Additional comment from Jan Silhan on 2015-07-21 05:49:06 EDT --- Reassigning to java-openjdk, please, fix your spec file (post scriplets). --- Additional comment from jiri vanek on 2015-07-21 07:40:56 EDT --- Hi! What is the diffeence between yum and dnf whic can cause it? What is this ts.addReinstall --- Additional comment from jiri vanek on 2015-08-11 08:28:43 EDT --- --- Additional comment from Deepak Bhole on 2015-08-11 16:23:31 EDT --- Adding NEEDINFO based on comment #7 --- Additional comment from jiri vanek on 2015-08-13 03:50:12 EDT --- (In reply to Jan Silhan from comment #1) > Thanks for the report. Probably wrong scriplets. DNF uses the > `ts.addReinstall` rpm method in contrast to yum. Are you pointing to this api? yum.baseurl.org/api/yum-3.2.27/yum.transactioninfo.TransactionData-class.html If so, why dnf changedt it from yum's original schmema? --- Additional comment from Jan Silhan on 2015-08-14 09:03:29 EDT --- I am not able to reproduce it. It works for me. Is it possible it's fixed in 1.8.0_51? # sudo dnf reinstall java-1.8.0-openjdk-headless -y ... java -version openjdk version "1.8.0_51-debug" OpenJDK Runtime Environment (build 1.8.0_51-debug-b16) OpenJDK 64-Bit Server VM (build 25.51-b03-debug, mixed mode) (In reply to jiri vanek from comment #10) > (In reply to Jan Silhan from comment #1) > > Thanks for the report. Probably wrong scriplets. DNF uses the > > `ts.addReinstall` rpm method in contrast to yum. > > Are you pointing to this api? > > If so, why dnf changedt it from yum's original schmema? This is the difference [1] from yum (the same it used to be in DNF). The change was made because of bug 1071854. [1] https://github.com/rpm-software-management/dnf/commit/516aad977e108df0f99c0bfc03a25b180888937f --- Additional comment from Heldwin on 2015-08-14 09:39:21 EDT --- still the same for me, and I have: java-1.8.0-openjdk-headless-1:1.8.0.51-4.b16.fc22.x86_64 --- Additional comment from Heldwin on 2015-08-14 09:48:26 EDT --- dnf-1.1.0-2.fc22.noarch dnf-plugins-core-0.1.10-1.fc22.noarch python-dnf-1.1.0-2.fc22.noarch hawkey-0.6.0-1.fc22.x86_64 python-hawkey-0.6.0-1.fc22.x86_64 just a reinstall didn't correct the java path, so I removed it and installed it again to see. It found java again, but then a reinstall made it loose it again. --- Additional comment from Heldwin on 2015-08-15 10:11:36 EDT --- --- Additional comment from Heldwin on 2015-08-15 10:15:24 EDT --- if I use: rpm -Uvh --force rpm -Uvh --force java-1.8.0-openjdk-headless-1.8.0.51-4.b16.fc22.x86_64.rpm or: yum-deprecated reinstall java-1.8.0-openjdk-headless after the system cannot find java, it then can find it. If I reinstall with dnf, and then run the commands in attachment 1063275 [details], it also can find the java command again. --- Additional comment from Heldwin on 2015-08-15 10:17:17 EDT --- sorry... bad copy/paste rpm -Uvh --force java-1.8.0-openjdk-headless-1.8.0.51-4.b16.fc22.x86_64.rpm --- Additional comment from Roger Wells on 2015-09-03 16:22:08 EDT --- I can confirm this. Thanks to everyone who tracked it down. The breaking of alternatives is very serious in those cases where a 32 bit java alternative is needed. An example might be Juniper Network's VPN which is much used in our office. --- Additional comment from jiri vanek on 2015-09-04 06:33:21 EDT --- After some digging this is what I see: Previous behaviour of dnf/rpm was: compelte erase of package (including its postuns) again istalling of package (including its posts) Now the behaviour is like update - http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering pre of package removal install post of package In case of openjdk, in post, we are removing what we added in pre. And it is quite necessary. Imho any scenario running POST after PRE do nto have sense... I'm inclining to move this bug to RPM (dnf?) again... --- Additional comment from jiri vanek on 2015-09-04 06:35:44 EDT --- I swapped pre with post and post with postu fix: post of package removal install postU of package In case of openjdk, in post, we are removing what we added in pre. And it is quite necessary. Imho any scenario running POSTU after POST do nto have sense... --- Additional comment from Jan Silhan on 2015-09-04 07:50:08 EDT --- Florian, is there any reason for this ^ scriplet execution order? In update it could make sense but in reinstall it's a little confusing. --- Additional comment from jiri vanek on 2015-09-04 08:24:54 EDT --- I made typo in above c#18. As c#19 was unclear explanation, here it is again: After some digging this is what I see: Previous behaviour of dnf/rpm was: compelte erase of package (including its postuns) again istalling of package (including its posts) Now the behaviour is like update - http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering post of package removal install postun of package In case of openjdk, in postun, we are removing what we added in post. And it is quite necessary. Imho any scenario running POSTUN after POST do not have sense... I'm inclining to move this bug to RPM (dnf?) again... --- Additional comment from Severin Gehwolf on 2015-09-09 12:25:56 EDT --- (In reply to Jan Silhan from comment #20) > Florian, is there any reason for this ^ scriplet execution order? In update > it could make sense but in reinstall it's a little confusing. [1] and [2] seem to answer this question, no? Since new dnf uses rpm's --reinstall that's the expected order. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1071854#c8 [2] https://bugzilla.redhat.com/show_bug.cgi?id=966715#c7 --- Additional comment from jiri vanek on 2015-09-10 04:35:33 EDT --- (In reply to Severin Gehwolf from comment #22) > (In reply to Jan Silhan from comment #20) > > Florian, is there any reason for this ^ scriplet execution order? In update > > it could make sense but in reinstall it's a little confusing. > > [1] and [2] seem to answer this question, no? Since new dnf uses rpm's > --reinstall that's the expected order. Well, yes - expected - But have this order sense[3] for reinstall? > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1071854#c8 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=966715#c7 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1260702 --- Additional comment from Severin Gehwolf on 2015-09-10 09:53:56 EDT --- (In reply to jiri vanek from comment #23) > (In reply to Severin Gehwolf from comment #22) > > (In reply to Jan Silhan from comment #20) > > > Florian, is there any reason for this ^ scriplet execution order? In update > > > it could make sense but in reinstall it's a little confusing. > > > > [1] and [2] seem to answer this question, no? Since new dnf uses rpm's > > --reinstall that's the expected order. > > Well, yes - expected - But have this order sense[3] for reinstall? Yes it makes sense to me. Considering bug 966715 there seem to be use cases where package re-installations may be done with different flags. In the bug --nodocs is the example. If re-install didn't remove docs first, docs would still be installed after re-install. Something similar is conceivable for files added during post/postun. For example RPM state files. [I] might be an example. [II] has more realistic examples it seems. Either way it's conceivable that %post creates a file/symlink/whatever %postun removes them. [I] https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Saving_state_between_scriptlets [II] http://rpm.org/api/4.4.2.2/triggers.html --- Additional comment from Severin Gehwolf on 2015-09-10 10:04:14 EDT --- For the record, the reproducer for this bug is either "rpm --reinstall": $ rpm -q java-1.8.0-openjdk java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64 $ dnf download java-1.8.0-openjdk{,-devel,-headless} $ java -version; sudo rpm --reinstall java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64.rpm java-1.8.0-openjdk-devel-1.8.0.60-14.b27.fc22.x86_64.rpm java-1.8.0-openjdk-headless-1.8.0.60-14.b27.fc22.x86_64.rpm; java -version openjdk version "1.8.0_60" OpenJDK Runtime Environment (build 1.8.0_60-b27) OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode) -bash: /usr/bin/java: No such file or directory Or "dnf reinstall": $ java -version; sudo dnf reinstall java-1.8.0-openjdk{,-devel,-headless} > /dev/null 2>&1; java -version openjdk version "1.8.0_60" OpenJDK Runtime Environment (build 1.8.0_60-b27) OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode) -bash: /usr/bin/java: No such file or directory It makes sense to me that rpm and dnf is consistent. --- Additional comment from Severin Gehwolf on 2015-09-10 10:06:17 EDT --- (In reply to Severin Gehwolf from comment #24) > (In reply to jiri vanek from comment #23) > > (In reply to Severin Gehwolf from comment #22) > > > (In reply to Jan Silhan from comment #20) > > > > Florian, is there any reason for this ^ scriplet execution order? In update > > > > it could make sense but in reinstall it's a little confusing. > > > > > > [1] and [2] seem to answer this question, no? Since new dnf uses rpm's > > > --reinstall that's the expected order. > > > > Well, yes - expected - But have this order sense[3] for reinstall? > > Yes it makes sense to me. Considering bug 966715 there seem to be use cases > where package re-installations may be done with different flags. In the bug > --nodocs is the example. If re-install didn't remove docs first, docs would > still be installed after re-install. Something similar is conceivable for > files added during post/postun. For example RPM state files. [I] might be an > example. [II] has more realistic examples it seems. Either way it's > conceivable that %post creates a file/symlink/whatever %postun removes them. > > [I] > https://fedoraproject.org/wiki/Packaging: > ScriptletSnippets#Saving_state_between_scriptlets > [II] http://rpm.org/api/4.4.2.2/triggers.html One more thing: https://bugzilla.redhat.com/show_bug.cgi?id=966715#c5 seems to suggest "rpm --reinstall" behaving like an update is by design. --- Additional comment from Severin Gehwolf on 2015-09-10 10:24:47 EDT --- So what to do now? Detect if we are a re-install and only remove alternatives if we aren't. --- Additional comment from jiri vanek on 2015-09-10 10:36:13 EDT --- Thats pretty terrible, isnt it? Even if it would notbe terrible by nature, then it will need to go to all javas in rhel8 - 3x oracle, 3x openjdk and 3x ibm. And keep telling another maintainers why it is here. I'm spending quite a lot of time to remove the terrible workarounds we have in spec by tweeking alternatives, rpm plugins and yum is in queue. Now - for tool of our future - dnf - I will need to add another hack? I simply cant accept this. And I quite insists that *soemthing* is wrong. The only workaround I'm willing to accept is, that http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax will be enhanced for reinstall column. And even then it will be still "wrong by design" (c#26). I'm not saying the idea itself is wrong. But it is not finished in manner of 1260702 With every chnage in underlying tools, Some workaround was added to specfiles, until they grow to current state. So for future tool of future packages this is no go. --- Additional comment from jiri vanek on 2016-02-29 03:58:36 EST --- This seems to be fixe!?!?! In dnf/rpm? What was the change? --- Additional comment from Adam Buraczewski on 2016-07-11 08:11:39 EDT --- I would like to confirm this bug for dnf 1.1.9 and OpenJDK 1.8.0.92 in Fedora 24. Reinstalling OpenJDK packages causes all java-related symlinks from /usr/bin, /usr/lib/jvm and /etc/alternatives to disappear. The only method of fixing them back is using "yum-deprecated reinstall" command.
Hello! I cloned this bug, because itneeds fixes both in dnf(rpm?) and openjdk. When read the
Hello! I cloned this bug
(sorry, pressed submit in middle of sentence) Hello! I cloned this bug, because this si not fixable in openjdk itself. When I re-read the bugs of 1260702 and 1200302 the only moreover acceptable solution is to make scriplets aware that it is reinstall. https://fedoraproject.org/wiki/Packaging:Scriptlets?rd=Packaging:ScriptletSnippets#Syntax install upgrade uninstall *reinstall* %pretrans $1 == 0 $1 == 0 (N/A) $1==3 or $2==1 %pre $1 == 1 $1 == 2 (N/A) $1==3 or $2==1 %post $1 == 1 $1 == 2 (N/A) $1==3 or $2==1 %preun (N/A) $1 == 1 $1 == 0 $1==3 or $2==1 %postun (N/A) $1 == 1 $1 == 0 $1==3 or $2==1 %posttrans $1 == 0 $1 == 0 (N/A) $1==3 or $2==1 Or something similar. Then I can fix openjdk packages, so on reinstall, the scrippelts will be abel to act.
we use RPM's reinstall(), so DNF has nothing to do with this
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
still alive
*** This bug has been marked as a duplicate of bug 1200302 ***