Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1200302 - dnf reinstall breaks alternatives
Summary: dnf reinstall breaks alternatives
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.8.0-openjdk
Version: rawhide
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
Assignee: jiri vanek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
: 1252406 1355687 1619725 1737304 (view as bug list)
Depends On: 1260702 1355687
Blocks: 1976053 1451158
TreeView+ depends on / blocked
 
Reported: 2015-03-10 09:23 UTC by Lukas Slebodnik
Modified: 2021-07-02 13:02 UTC (History)
34 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1355687 (view as bug list)
Environment:
Last Closed: 2018-05-29 11:53:48 UTC
Type: Bug


Attachments (Terms of Use)
alternatives commands that seems to be missing after reinstall (3.44 KB, text/plain)
2015-08-15 14:11 UTC, Heldwin
no flags Details
Example as to how to detect re-installs (1.09 KB, text/plain)
2015-09-10 14:24 UTC, Severin Gehwolf
no flags Details
Spec of testpkg which handles upgrades/reinstall with alternatives. (3.25 KB, text/plain)
2018-08-30 13:51 UTC, Severin Gehwolf
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1151650 0 unspecified CLOSED reinstalling kernel does not regenerate initramfs 2021-02-22 00:41:40 UTC

Internal Links: 1151650

Description Lukas Slebodnik 2015-03-10 09:23:13 UTC
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.

Comment 1 Honza Silhan 2015-03-24 11:14:21 UTC
Thanks for the report. Probably wrong scriplets. DNF uses the `ts.addReinstall` rpm method in contrast to yum.

Comment 2 Lukas Slebodnik 2015-03-24 11:23:07 UTC
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.

Comment 3 Lukas Slebodnik 2015-05-04 21:27:59 UTC
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?

Comment 4 Fedora Blocker Bugs Application 2015-05-08 11:55:08 UTC
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.

Comment 5 Dan Mossor [danofsatx] 2015-05-11 19:28:23 UTC
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/

Comment 6 Honza Silhan 2015-07-21 09:49:06 UTC
Reassigning to java-openjdk, please, fix your spec file (post scriplets).

Comment 7 jiri vanek 2015-07-21 11:40:56 UTC
Hi!

What is the diffeence between yum and dnf whic can cause it?

What is this ts.addReinstall

Comment 8 jiri vanek 2015-08-11 12:28:43 UTC
*** Bug 1252406 has been marked as a duplicate of this bug. ***

Comment 9 Deepak Bhole 2015-08-11 20:23:31 UTC
Adding NEEDINFO based on comment #7

Comment 10 jiri vanek 2015-08-13 07:50:12 UTC
(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?

Comment 11 Honza Silhan 2015-08-14 13:03:29 UTC
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

Comment 12 Heldwin 2015-08-14 13:39:21 UTC
still the same for me, and I have:
java-1.8.0-openjdk-headless-1:1.8.0.51-4.b16.fc22.x86_64

Comment 13 Heldwin 2015-08-14 13:48:26 UTC
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.

Comment 14 Heldwin 2015-08-15 14:11:36 UTC
Created attachment 1063275 [details]
alternatives commands that seems to be missing after reinstall

Comment 15 Heldwin 2015-08-15 14:15:24 UTC
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.

Comment 16 Heldwin 2015-08-15 14:17:17 UTC
sorry... bad copy/paste
rpm -Uvh --force java-1.8.0-openjdk-headless-1.8.0.51-4.b16.fc22.x86_64.rpm

Comment 17 Roger Wells 2015-09-03 20:22:08 UTC
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.

Comment 18 jiri vanek 2015-09-04 10:33:21 UTC
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...

Comment 19 jiri vanek 2015-09-04 10:35:44 UTC
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...

Comment 20 Honza Silhan 2015-09-04 11:50:08 UTC
Florian, is there any reason for this ^ scriplet execution order? In update it could make sense but in reinstall it's a little confusing.

Comment 21 jiri vanek 2015-09-04 12:24:54 UTC
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...

Comment 22 Severin Gehwolf 2015-09-09 16:25:56 UTC
(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

Comment 23 jiri vanek 2015-09-10 08:35:33 UTC
(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

Comment 24 Severin Gehwolf 2015-09-10 13:53:56 UTC
(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

Comment 25 Severin Gehwolf 2015-09-10 14:04:14 UTC
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.

Comment 26 Severin Gehwolf 2015-09-10 14:06:17 UTC
(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.

Comment 27 Severin Gehwolf 2015-09-10 14:24:47 UTC
Created attachment 1072210 [details]
Example as to how to detect re-installs

So what to do now? Detect if we are a re-install and only remove alternatives if we aren't.

Comment 28 jiri vanek 2015-09-10 14:36:13 UTC
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.

Comment 29 jiri vanek 2016-02-29 08:58:36 UTC
This seems to be fixe!?!?! In dnf/rpm? What was the change?

Comment 30 Adam Buraczewski 2016-07-11 12:11:39 UTC
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.

Comment 31 jiri vanek 2016-07-12 09:05:27 UTC
*** Bug 1252406 has been marked as a duplicate of this bug. ***

Comment 32 Fedora End Of Life 2016-07-19 20:19:06 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 33 Omair Majid 2016-07-19 20:27:46 UTC
Moving to F24 based on comment 30.

Comment 34 Florian Festi 2016-10-24 12:09:26 UTC
Oh, there is still an needinfo open: 

The new reinstall implementation of rpm does what we consider the right thing: Removing the package and install the package. As always rpm avoids having no files on the disk at some point by doing the installation first.

Right way to solve this would be having scriptlets that are robust enough to do the right thing in such an situation.

Comment 35 jiri vanek 2016-10-24 13:00:01 UTC
To do so, I need information that it is reinstall what is happening.
otherwise I will end in some terrible /tmp/reinstal_is_hapenning fragile hack.

Comment 36 Lukas Slebodnik 2016-10-24 13:15:52 UTC
(In reply to jiri vanek from comment #35)
> To do so, I need information that it is reinstall what is happening.
> otherwise I will end in some terrible /tmp/reinstal_is_hapenning fragile
> hack.

I think that this can be detected with "$1 == 2" (row -> %post, column -> upgrade) based on following table
https://fedoraproject.org/wiki/Packaging:Scriptlets?rd=Packaging:ScriptletSnippets#Syntax

Comment 37 jiri vanek 2016-10-24 13:30:56 UTC
(In reply to Lukas Slebodnik from comment #36)
> (In reply to jiri vanek from comment #35)
> > To do so, I need information that it is reinstall what is happening.
> > otherwise I will end in some terrible /tmp/reinstal_is_hapenning fragile
> > hack.
> 
> I think that this can be detected with "$1 == 2" (row -> %post, column ->
> upgrade) based on following table
> https://fedoraproject.org/wiki/Packaging:Scriptlets?rd=Packaging:
> ScriptletSnippets#Syntax

Thats not the same and was already discussed in this bug. My packages upgrade fine. The reinstall is what meters. As it is no install nor update.

Small summary

In post I'm creating link with NVR2
In postun I'm removing link with NVR1

So if it is update, and nvr1 != nvr2 then  (because of scriplet ordering) nvr2 remains on system as nvr1 removes just nvr1.

However on reinstall, where nvr1==nvr2, the postun sucesfully removes results of post.

Comment 38 Fedora End Of Life 2017-07-25 18:51:22 UTC
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.

Comment 39 Lukas Slebodnik 2017-07-25 19:37:17 UTC
Deterministically reproducible even on fedora 26

Comment 40 Thomas Daniell 2018-04-07 07:56:25 UTC
After doing dnf reinstall '*' on Fedora 27 (probably a stupid thing to do) the symbolic link /usr/bin/java was deleted, so this is still an issue. 'alternatives --list' contains no entry for java.

Comment 41 jiri vanek 2018-04-09 08:34:52 UTC
(In reply to Thomas Daniell from comment #40)
> After doing dnf reinstall '*' on Fedora 27 (probably a stupid thing to do)
> the symbolic link /usr/bin/java was deleted, so this is still an issue.
> 'alternatives --list' contains no entry for java.

Workaround is second reinstall. I'm really sorry for your troubles. Any Idea how to fix this is welcommed.

Comment 42 Heldwin 2018-04-09 18:39:20 UTC
reinstalling java-1.8.0-openjdk-headless, breaks java on f28 though.

I don't do it very often, and I don't see a need to do it, except when trying to recover a bad system update, so I am not sure if it is also the case in f27

Comment 43 Thomas Daniell 2018-04-11 05:26:34 UTC
(In reply to jiri vanek from comment #41)
> (In reply to Thomas Daniell from comment #40)
> > After doing dnf reinstall '*' on Fedora 27 (probably a stupid thing to do)
> > the symbolic link /usr/bin/java was deleted, so this is still an issue.
> > 'alternatives --list' contains no entry for java.
> 
> Workaround is second reinstall. I'm really sorry for your troubles. Any Idea
> how to fix this is welcommed.

Thats all good :). I ended up fixing it by using the alternatives --install command to manually recreate the symbolic link (reinstalling just the java packages like java-1.8.0-openjdk didn't fix the problem unfortunately).

Comment 44 Fedora End Of Life 2018-05-03 08:10:31 UTC
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.

Comment 45 Fedora End Of Life 2018-05-29 11:53:48 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 46 jiri vanek 2018-05-29 12:59:52 UTC
persisting and anoying

Comment 47 Panu Matilainen 2018-06-29 13:26:19 UTC
*** Bug 1355687 has been marked as a duplicate of this bug. ***

Comment 48 Jan Kurik 2018-08-14 10:31:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 49 Jonathan Underwood 2018-08-21 15:49:31 UTC
*** Bug 1619725 has been marked as a duplicate of this bug. ***

Comment 50 Jonathan Underwood 2018-08-21 15:58:42 UTC
I just hit this bug in Fedora 28. Reading through the comments, it seems like, in 3.5 years, there hasn't been any agreement on exactly where the problem lies, and where it should be fixed. It would be great to move this forward.

What is the current concensus on the root cause of this problem?

Comment 51 jiri vanek 2018-08-23 14:48:49 UTC
HI!

There is no agreement.   OpenJDK to work correctly, as is now, needs information that it is reinstall. Rpm tool refuse to provide this information. 
We can hardly change the scripletorder, and  I dont know how to workaroundit.

Comment 52 Jonathan Underwood 2018-08-23 20:50:34 UTC
(In reply to jiri vanek from comment #51)
> HI
> 
> There is no agreement.   OpenJDK to work correctly, as is now, needs
> information that it is reinstall. Rpm tool refuse to provide this
> information. 
> We can hardly change the scripletorder, and  I dont know how to workaroundit.

Ok, so we've established that reinstall runs scriptures in the same order as upgrade.

However, that being the case, the postun script should NOT run according to this:

https://fedoraproject.org/wiki/Packaging:Scriptlets?rd=Packaging:ScriptletSnippets#Syntax

"$1 (for shell scripts) is the number of packages of this name which will be left on the system when the action completes"

So, during a reinstall $1 should surely be 1, not 0. That being so the script in postun would not fire (due to the $1 == 0 condition.

THAT seems to be the bug.

Comment 53 Jonathan Underwood 2018-08-25 18:46:03 UTC
OK I have confirmed that this is a bug that should be fixed in the java-openjdk package.

With package created from the following spec file:

Name:           testpkg
Version:        1.0
Release:        1%{?dist}
Summary:        A test package for reinstalling
License:        GPL
URL:            https://fedoraproject.org


%description
A test package.

%prep
# None

%build
# None

%post
echo post: $1

%postun
echo postun: $1

%install
# None

%files
# None

%changelog


we see:


(1) dnf install testpkg-1.0-1.fc28.x86_64.rpm
[...]
Running transaction
  Preparing        :                                                        1/1 
  Installing       : testpkg-1.0-1.fc28.x86_64                              1/1 
  Running scriptlet: testpkg-1.0-1.fc28.x86_64                              1/1 
post: 1
  Verifying        : testpkg-1.0-1.fc28.x86_64                              1/1 

Installed:
  testpkg.x86_64 1.0-1.fc28                                                     

(2) dnf reinstall testpkg-1.0-1.fc28.x86_64.rpm
[...]
Running transaction
  Preparing        :                                                        1/1 
  Reinstalling     : testpkg-1.0-1.fc28.x86_64                              1/2 
  Running scriptlet: testpkg-1.0-1.fc28.x86_64                              1/2 
post: 2
  Erasing          : testpkg-1.0-1.fc28.x86_64                              2/2 
  Running scriptlet: testpkg-1.0-1.fc28.x86_64                              2/2 
postun: 1
  Verifying        : testpkg-1.0-1.fc28.x86_64                              1/2 
  Verifying        : testpkg-1.0-1.fc28.x86_64                              2/2 

Reinstalled:
  testpkg.x86_64 1.0-1.fc28


(3) dnf remove testpkg
[...]
Running transaction
  Preparing        :                                                        1/1 
  Erasing          : testpkg-1.0-1.fc28.x86_64                              1/1 
  Running scriptlet: testpkg-1.0-1.fc28.x86_64                              1/1 
postun: 0
  Verifying        : testpkg-1.0-1.fc28.x86_64                              1/1 

Removed:
  testpkg.x86_64 1.0-1.fc28



So, in java-openjdk, so long as the script in postun is guarded with a conditional to only run if $1 == 0, then the problem with reinstall removing the alternatives entries would be fixed.

In other words, rpm already provides the facility to know if a scriptlet is being run during a reinstall or a uninstall.

The fact that the rather complicated nested macro expansion in the java-openjdk doesn't work is, I believe, a bug with the java-openjdk package, not rpm. Re-assigning back to the java-openjdk package. 

I would try to help further, but the complexity of the nested macro usage in the java-openjdk spec file is beyond me - does the spec file really need to be this convoluted?

Comment 54 Jonathan Underwood 2018-08-25 18:53:05 UTC
Also, just for completeness:

(4) dnf install testpkg-1.0-2.fc28.x86_64.rpm
[...]
Running transaction
  Preparing        :                                                        1/1 
  Installing       : testpkg-1.0-2.fc28.x86_64                              1/1 
  Running scriptlet: testpkg-1.0-2.fc28.x86_64                              1/1 
post: 1
  Verifying        : testpkg-1.0-2.fc28.x86_64                              1/1

Comment 55 Jonathan Underwood 2018-08-25 20:35:21 UTC
Naive fix:

https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/pull-request/15

Comment 56 Severin Gehwolf 2018-08-30 10:05:02 UTC
Minimal package spec to reproduce the issue with alternatives. That package installs testpkg-script in /usr/bin via alternatives. The actual script, managed by alternatives, resides in a unique location in /usr/share/<NVR>.<ARCH>/bin:

%global         uniqueprefix    %{name}-%{version}-%{release}.%{_arch}
%global         bindir          %{_datadir}/%{uniqueprefix}/bin
%global         major           1
# priority must be 7 digits in total
# setting to 1, so debug ones can have 0
%global         priority        000000%{major}

Name:           testpkg
Version:        %{major}.0
Release:        1%{?dist}
Summary:        Test package for re-install

License:        GPL
URL:            https://fedoraproject.org

%description
A test package

%prep
# nothing

%build
cat > %{name}-script <<END
#!/bin/bash
echo %{name}-script from %{uniqueprefix}
exit 0
END

%install
mkdir -p %{buildroot}%{bindir}
install -m 755 %{name}-script %{buildroot}%{bindir}/%{name}-script

%post
echo post: %{uniqueprefix} - $1
alternatives \
  --install %{_bindir}/%{name}-script %{name}-script %{bindir}/%{name}-script %{priority}  --family %{name}.%{_arch}

%postun
echo postun: %{uniqueprefix} - $1
alternatives --remove %{name}-script %{bindir}/%{name}-script

%files
%{bindir}

%changelog
* Thu Aug 30 2018 Severin Gehwolf <sgehwolf@redhat.com> - 1.0-1
- Initial test pkg


$ dnf install -y ../RPMS/x86_64/testpkg-1.0-1.fc28.x86_64.rpm 
Running transaction
  Preparing        :                                                                                                                                                                                           1/1 
  Installing       : testpkg-1.0-1.fc28.x86_64                                                                                                                                                                 1/1 
  Running scriptlet: testpkg-1.0-1.fc28.x86_64                                                                                                                                                                 1/1 
post: testpkg-1.0-1.fc28.x86_64 - 1
  Verifying        : testpkg-1.0-1.fc28.x86_64                                                                                                                                                                 1/1 

Installed:
  testpkg.x86_64 1.0-1.fc28                                                                                                                                                                                        

Complete!
$ testpkg-script
testpkg-script from testpkg-1.0-1.fc28.x86_64

$ dnf reinstall -y ../RPMS/x86_64/testpkg-1.0-1.fc28.x86_64.rpm
Running transaction
  Preparing        :                                                                                                                                                                                           1/1 
  Reinstalling     : testpkg-1.0-1.fc28.x86_64                                                                                                                                                                 1/2 
  Running scriptlet: testpkg-1.0-1.fc28.x86_64                                                                                                                                                                 1/2 
post: testpkg-1.0-1.fc28.x86_64 - 2
  Erasing          : testpkg-1.0-1.fc28.x86_64                                                                                                                                                                 2/2 
  Running scriptlet: testpkg-1.0-1.fc28.x86_64                                                                                                                                                                 2/2 
postun: testpkg-1.0-1.fc28.x86_64 - 1
  Verifying        : testpkg-1.0-1.fc28.x86_64                                                                                                                                                                 1/2 
  Verifying        : testpkg-1.0-1.fc28.x86_64                                                                                                                                                                 2/2 

Reinstalled:
  testpkg.x86_64 1.0-1.fc28                                                                                                                                                                                        

Complete!

$ testpkg-script
bash: /usr/bin/testpkg-script: No such file or directory

So we've reproduced this bug with a simpler package.

Comment 57 Severin Gehwolf 2018-08-30 10:18:10 UTC
Now lets look at the proposed solution with:

%global         uniqueprefix    %{name}-%{version}-%{release}.%{_arch}
%global         bindir          %{_datadir}/%{uniqueprefix}/bin
%global         major           1
# priority must be 7 digits in total
# setting to 1, so debug ones can have 0
%global         priority        000000%{major}

Name:           testpkg
Version:        %{major}.0
Release:        2%{?dist}
Summary:        Test package for re-install

License:        GPL
URL:            https://fedoraproject.org

%description
A test package

%prep
# nothing

%build
cat > %{name}-script <<END
#!/bin/bash
echo %{name}-script from %{uniqueprefix}
exit 0
END

%install
mkdir -p %{buildroot}%{bindir}
install -m 755 %{name}-script %{buildroot}%{bindir}/%{name}-script

%post
echo post: %{uniqueprefix} - $1
alternatives \
  --install %{_bindir}/%{name}-script %{name}-script %{bindir}/%{name}-script %{priority}  --family %{name}.%{_arch}

%postun
echo postun: %{uniqueprefix} - $1
if [ $1 -eq 0 ] ; then
    echo removing alternatives for %{uniqueprefix}
    alternatives --remove %{name}-script %{bindir}/%{name}-script
fi

%files
%{bindir}

%changelog
* Thu Aug 30 2018 Severin Gehwolf <sgehwolf@redhat.com> - 1.0-2
- Proposed solution with $1 -eq 0 check.

* Thu Aug 30 2018 Severin Gehwolf <sgehwolf@redhat.com> - 1.0-1
- Initial test pkg

$ rpm -q testpkg
package testpkg is not installed
$ sudo dnf install -y ../RPMS/x86_64/testpkg-1.0-2.fc28.x86_64.rpm
Running transaction
  Preparing        :                                                                                                                                                                                           1/1 
  Installing       : testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 1/1 
  Running scriptlet: testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 1/1 
post: testpkg-1.0-2.fc28.x86_64 - 1
  Verifying        : testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 1/1 

Installed:
  testpkg.x86_64 1.0-2.fc28                                                                                                                                                                                        

Complete!

$ testpkg-script
testpkg-script from testpkg-1.0-2.fc28.x86_64

$ sudo dnf reinstall -y ../RPMS/x86_64/testpkg-1.0-2.fc28.x86_64.rpm
Running transaction
  Preparing        :                                                                                                                                                                                           1/1 
  Reinstalling     : testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 1/2 
  Running scriptlet: testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 1/2 
post: testpkg-1.0-2.fc28.x86_64 - 2
  Erasing          : testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 2/2 
  Running scriptlet: testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 2/2 
postun: testpkg-1.0-2.fc28.x86_64 - 1
  Verifying        : testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 1/2 
  Verifying        : testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 2/2 

Reinstalled:
  testpkg.x86_64 1.0-2.fc28                                                                                                                                                                                        

Complete!
$ testpkg-script
testpkg-script from testpkg-1.0-2.fc28.x86_64

OK. Reinstall works Bug how about upgrade?

$ rpmdev-bumpspec testpkg.spec 
$ git diff
diff --git a/testpkg.spec b/testpkg.spec
index c7387cc..d49f77a 100644
--- a/testpkg.spec
+++ b/testpkg.spec
@@ -7,7 +7,7 @@
 
 Name:           testpkg
 Version:        %{major}.0
-Release:        2%{?dist}
+Release:        3%{?dist}
 Summary:        Test package for re-install
 
 License:        GPL
@@ -46,6 +46,9 @@ fi
 %{bindir}
 
 %changelog
+* Thu Aug 30 2018 Severin Gehwolf <sgehwolf@redhat.com> - 1.0-3
+- rebuilt
+
 * Thu Aug 30 2018 Severin Gehwolf <sgehwolf@redhat.com> - 1.0-2
 - Proposed solution with $1 -eq 0 check.

$ rpm -q testpkg
testpkg-1.0-2.fc28.x86_64
$ testpkg-script
testpkg-script from testpkg-1.0-2.fc28.x86_64
$ $ sudo dnf install -y ../RPMS/x86_64/testpkg-1.0-3.fc28.x86_64.rpm 
Last metadata expiration check: 0:15:58 ago on Thu 30 Aug 2018 11:58:54 AM CEST.
Dependencies resolved.
===================================================================================================================================================================================================================
 Package                                          Arch                                            Version                                              Repository                                             Size
===================================================================================================================================================================================================================
Upgrading:
 testpkg                                          x86_64                                          1.0-3.fc28                                           @commandline                                          7.5 k

Transaction Summary
===================================================================================================================================================================================================================
Upgrade  1 Package

Total size: 7.5 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                                           1/1 
  Upgrading        : testpkg-1.0-3.fc28.x86_64                                                                                                                                                                 1/2 
  Running scriptlet: testpkg-1.0-3.fc28.x86_64                                                                                                                                                                 1/2 
post: testpkg-1.0-3.fc28.x86_64 - 2
  Cleanup          : testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 2/2 
  Running scriptlet: testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 2/2 
postun: testpkg-1.0-2.fc28.x86_64 - 1
  Verifying        : testpkg-1.0-3.fc28.x86_64                                                                                                                                                                 1/2 
  Verifying        : testpkg-1.0-2.fc28.x86_64                                                                                                                                                                 2/2 

Upgraded:
  testpkg.x86_64 1.0-3.fc28                                                                                                                                                                                        

Complete!
$ testpkg-script
bash: testpkg-script: command not found...
$ alternatives --display testpkg-script
testpkg-script - status is auto.
 link currently points to /usr/share/testpkg-1.0-2.fc28.x86_64/bin/testpkg-script
/usr/share/testpkg-1.0-2.fc28.x86_64/bin/testpkg-script - family testpkg.x86_64 priority 1
/usr/share/testpkg-1.0-3.fc28.x86_64/bin/testpkg-script - family testpkg.x86_64 priority 1
Current `best' version is /usr/share/testpkg-1.0-2.fc28.x86_64/bin/testpkg-script.

So with the proposed solution this will break upgrades. The reason for it is that alternatives will point to the old install location, /usr/share/testpkg-1.0-2.fc28.x86_64/bin/testpkg-script, instead of the new one post-upgrade, /usr/share/testpkg-1.0-3.fc28.x86_64/bin/testpkg-script

Comment 58 Severin Gehwolf 2018-08-30 10:19:47 UTC
(In reply to Jonathan Underwood from comment #55)
> Naive fix:
> 
> https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/pull-request/15

Unfortunately this won't work on its own. See comment 57. I'm going to close this pull request.

Comment 59 Severin Gehwolf 2018-08-30 10:22:46 UTC
(In reply to Jonathan Underwood from comment #53)
> In other words, rpm already provides the facility to know if a scriptlet is
> being run during a reinstall or a uninstall.

While that's true rpm does not seem to provide a means to distinguish between reinstall and upgrade. See comment 57 where both a reinstall and then an upgrade is performed.

Comment 60 Jonathan Underwood 2018-08-30 10:32:03 UTC
But why are we installing to NVR specific directories? That seems unnecessary.

Comment 61 Severin Gehwolf 2018-08-30 11:27:24 UTC
(In reply to Jonathan Underwood from comment #60)
> But why are we installing to NVR specific directories? That seems
> unnecessary.

Because one can parallel install multiple versions of the JDK without a conflict (via installonlypkgs= in /etc/dnf/dnf.conf). That's a feature we are not ready to remove.

Comment 62 Severin Gehwolf 2018-08-30 13:51:58 UTC
Created attachment 1479818 [details]
Spec of testpkg which handles upgrades/reinstall with alternatives.

Proof of concept spec file of 'testpkg' which handles upgrades/reinstall and alternatives. It seems to work for all the relevant cases, though it uses RPM state and posttrans. I don't think there is any other way.

Comment 63 Jonathan Underwood 2018-08-30 14:04:00 UTC
I really struggle to see the extra value of parallel installable NVR packages that justifies all this extra complexity and fragility. The resulting spec file really discourages community collaboration too.

Comment 64 jiri vanek 2018-09-03 11:12:19 UTC
(In reply to Severin Gehwolf from comment #62)
> Created attachment 1479818 [details]
> Spec of testpkg which handles upgrades/reinstall with alternatives.
> 
> Proof of concept spec file of 'testpkg' which handles upgrades/reinstall and
> alternatives. It seems to work for all the relevant cases, though it uses

That is scary

> RPM state and posttrans. I don't think there is any other way.

That is double scary.


But thanx for bringing the idea about marking itself in transaction.

One nit - %{rpm_state_dir}/upgrade is very common. %{rpm_state_dir} is not  package=specific, so somthing like: %{rpm_state_dir}/%{name} is necessary.
In our case, this can be more complicated, as java-openjdk and java-11-openjdk will share targets once jdk10 eol. So we will need %{rpm_state_dir}/java-%{javaver}-%{origin}
In that dir we can do hopefully anything we wont.

Maybe easier approach can be:
%global state_file=%{rpm_state_dir}/java-%{javaver}-%{origin}/upgrade
...

%pre
echo %{uniqueprefix} > %{state_file}

%postun
nw=`cat  %{state_file}`
reinstall=false
if [ $nw ==  %{uniqueprefix} ] ; then
reinstall=true
fi

Comment 65 Severin Gehwolf 2018-09-03 11:34:05 UTC
(In reply to jiri vanek from comment #64)
> (In reply to Severin Gehwolf from comment #62)
> > Created attachment 1479818 [details]
> > Spec of testpkg which handles upgrades/reinstall with alternatives.
> > 
> > Proof of concept spec file of 'testpkg' which handles upgrades/reinstall and
> > alternatives. It seems to work for all the relevant cases, though it uses
> 
> That is scary
> 
> > RPM state and posttrans. I don't think there is any other way.
> 
> That is double scary.
> 
> 
> But thanx for bringing the idea about marking itself in transaction.
> 
> One nit - %{rpm_state_dir}/upgrade is very common. %{rpm_state_dir} is not 
> package=specific, so somthing like: %{rpm_state_dir}/%{name} is necessary.
> In our case, this can be more complicated, as java-openjdk and
> java-11-openjdk will share targets once jdk10 eol. So we will need
> %{rpm_state_dir}/java-%{javaver}-%{origin}
> In that dir we can do hopefully anything we wont.
> 
> Maybe easier approach can be:
> %global state_file=%{rpm_state_dir}/java-%{javaver}-%{origin}/upgrade
> ...

From the spec file of testpkg:

%global         rpm_state_dir   %{_localstatedir}/lib/rpm-state/%{name}

So it uses a package specific directory.

Comment 66 jiri vanek 2018-09-03 11:47:58 UTC
Sorry, overlooked that.

Still the java-openjdk x java-version-openjdk is valid note.

Comment 67 Severin Gehwolf 2018-09-03 11:58:45 UTC
(In reply to jiri vanek from comment #66)
> Still the java-openjdk x java-version-openjdk is valid note.

Have we considered making java-openjdk install in a version neutral location? Something like /usr/lib/jvm/java-latest-openjdk would avoid this, no?

Either way we should extend the very minimal example(s) to simulate the behaviour and test with it/them. We should also keep them for reference as we'd like to preserve info gathered in this bug.

Comment 68 Jonathan Underwood 2018-09-03 12:47:25 UTC
Could someone please outline the use cases for having multiple NVR packages installed simultaneously. The complexity and fragility of the approaches being discussed here, and the detrimental impact on community collaboration really needs weighing up.

Comment 69 jiri vanek 2018-09-03 13:00:12 UTC
Maybe because of the dark ages of OpenJDK, people are scared of java updates. We are constantly queered "I can download oracle jdk zip, unpack it and experiment with it. Can I do it wit RPMs?" So this is an answer. You can install any major and minor jdks in parallel, and switch between them via alternatives

As yum/dnf refused support for this  "kernel like" approach, we went with our complex spec files.

As you usually do not need this feature, the JDK updates "as usually". You can mark ti as install only in dnf.conf, and then JDKs are being added into your system, and they canbe switched. Of course you can install java-1.8.0-openjdk, java-10-openjdk and java-11-openjdk alongside, as those are separate packages with separate update cycles.

Comment 70 Göran Uddeborg 2019-08-05 19:02:29 UTC
Wouldn't a way to solve the problem be to check for the existence of the thing to (potentially) remove from alternatives?  If it is still there, don't remove it.

    if ! [ -e /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.fc30.x86_64/jre/bin/java ]
    then alternatives --remove java /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.fc30.x86_64/jre/bin/java
    fi

And similarly for the other entries.  With the appropriate variables for name, version, and release, of course.

Call it a workaround if you like.  Would you find it too ugly?

Comment 71 jiri vanek 2019-08-21 14:08:14 UTC
*** Bug 1737304 has been marked as a duplicate of this bug. ***

Comment 72 Ben Cotton 2019-10-31 18:55:45 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-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 '29'.

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 29 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.

Comment 73 Jonathan Underwood 2020-01-26 15:14:31 UTC
(In reply to jiri vanek from comment #69)
> Maybe because of the dark ages of OpenJDK, people are scared of java
> updates. We are constantly queered "I can download oracle jdk zip, unpack it
> and experiment with it. Can I do it wit RPMs?" So this is an answer. You can
> install any major and minor jdks in parallel, and switch between them via
> alternatives
> 
> As yum/dnf refused support for this  "kernel like" approach, we went with
> our complex spec files.
> 
> As you usually do not need this feature, the JDK updates "as usually". You
> can mark ti as install only in dnf.conf, and then JDKs are being added into
> your system, and they canbe switched. Of course you can install
> java-1.8.0-openjdk, java-10-openjdk and java-11-openjdk alongside, as those
> are separate packages with separate update cycles.

I could make the same arguments for every single package in Fedora. But this is an absolute niche use case, and that's why we don't do that. Fedora is supposed to be a robust, coherent distribution of packages. OpenJDK packaging is going in a completely different direction to anything else (except the kernel) in Fedora, and it's resulting in broken behaviour, lack of community participation, complexity and fragility.

Comment 74 Ben Cotton 2020-04-30 20:25:24 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-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 '30'.

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 30 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.

Comment 75 Severin Gehwolf 2020-05-04 07:53:24 UTC
This is still an issue in F32.

Comment 76 Derek Atkins 2021-01-29 13:37:51 UTC
For the record, I just hit this in Fedora 33.
I see it both with java-1.8.0-openjdk-headless and java-11-openjdk-headless

I just tried:
dnf downgrade java-11-openjdk-headless
and I got the following:

  Running scriptlet: java-11-openjdk-headless-1:11.0.9.11-9.fc33.x86_64     6/6 
/usr/lib/jvm/java-11-openjdk-11.0.9.11-9.fc33.x86_64/bin/java has not been configured as an alternative for java
/usr/lib/jvm/java-11-openjdk-11.0.9.11-9.fc33.x86_64 has not been configured as an alternative for jre_openjdk
/usr/lib/jvm/java-11-openjdk-11.0.9.11-9.fc33.x86_64 has not been configured as an alternative for jre_11
/usr/lib/jvm/jre-11-openjdk-11.0.9.11-9.fc33.x86_64 has not been configured as an alternative for jre_11_openjdk
warning: %postun(java-11-openjdk-headless-1:11.0.9.11-9.fc33.x86_64) scriptlet failed, exit status 2

Error in POSTUN scriptlet in rpm package java-11-openjdk-headless..  BUT I now see valid results for "alternatives --display java", which I did not before.

Then I run dnf-update java-11-openjdk-headless and the alternatives are still there.  So I think this is a valid workaround until this issue is fixed:

dnf downgrade java-11-openjdk-headless
dnf upgrade java-11-openjdk-headless

Comment 77 Christian Wissel 2021-04-21 15:06:29 UTC
Can confirm the downgrade -> upgrade workaround resolves this.
However, I find it ridiculous that this bug from 2015 is still alive and kicking in 2021.

Comment 78 Fedora Program Management 2021-04-29 17:12:27 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
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 '32'.

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 32 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.

Comment 79 jiri vanek 2021-04-30 11:50:50 UTC
(In reply to Christian Wissel from comment #77)
> Can confirm the downgrade -> upgrade workaround resolves this.
> However, I find it ridiculous that this bug from 2015 is still alive and
> kicking in 2021.

Sorry. The fix is known. But it is terrible over-engineered and would cause maintenance hell.

Comment 80 Peter Ajamian 2021-06-25 10:43:54 UTC
Ummm, has anyone actually considered the solution to this that is in the Fedora Packaging Guidelines and is tailor made to solve this very problem?

https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/

Note the %postun example:

%postun
if [ $1 -eq 0 ] ; then
  %{_sbindir}/update-alternatives --remove %{name} %{_bindir}/antlr-java
fi

So just wrap the alternatives --remove commands in if [ $1 -eq 0 ] ; then ... fi and be done with it.  This works (as it's designed to) with dnf, yum, rpm, you name it.

Comment 81 jiri vanek 2021-06-29 13:23:53 UTC
(In reply to Peter Ajamian from comment #80)
> Ummm, has anyone actually considered the solution to this that is in the
> Fedora Packaging Guidelines and is tailor made to solve this very problem?
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
> 
> Note the %postun example:
> 
> %postun
> if [ $1 -eq 0 ] ; then
>   %{_sbindir}/update-alternatives --remove %{name} %{_bindir}/antlr-java
> fi
> 
> So just wrap the alternatives --remove commands in if [ $1 -eq 0 ] ; then
> ... fi and be done with it.  This works (as it's designed to) with dnf, yum,
> rpm, you name it.

Jsut to wrap up https://bugzilla.redhat.com/show_bug.cgi?id=1976053 - There was explained why above snippet can not be used, and interesting idea of setting alternatives in postrans was pledged. The PR for jdk11,8 and latest will follow.


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