Bug 1200302

Thanks for the report. Probably wrong scriplets. DNF uses the `ts.addReinstall` rpm method in contrast to yum.

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.

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?

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.

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/

Reassigning to java-openjdk, please, fix your spec file (post scriplets).

Hi!

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

What is this ts.addReinstall

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

Adding NEEDINFO based on comment #7

(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?

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

still the same for me, and I have:
java-1.8.0-openjdk-headless-1:1.8.0.51-4.b16.fc22.x86_64

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.

Created attachment 1063275 [details]
alternatives commands that seems to be missing after reinstall

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.

sorry... bad copy/paste
rpm -Uvh --force java-1.8.0-openjdk-headless-1.8.0.51-4.b16.fc22.x86_64.rpm

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.

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

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

Florian, is there any reason for this ^ scriplet execution order? In update it could make sense but in reinstall it's a little confusing.

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

(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

(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

(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

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.

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

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.

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.

This seems to be fixe!?!?! In dnf/rpm? What was the change?

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.

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

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.

Moving to F24 based on comment 30.

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.

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.

(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

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

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.

Deterministically reproducible even on fedora 26

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.

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

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

(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).

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.

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.

persisting and anoying

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

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

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

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?

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.

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

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?

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

Naive fix:

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

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

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> - 1.0-2
- Proposed solution with $1 -eq 0 check.

* Thu Aug 30 2018 Severin Gehwolf <sgehwolf> - 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> - 1.0-3
+- rebuilt
+
 * Thu Aug 30 2018 Severin Gehwolf <sgehwolf> - 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

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

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

But why are we installing to NVR specific directories? That seems unnecessary.

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

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.

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.

(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

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

Sorry, overlooked that.

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

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

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.

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.

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?

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

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.

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

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.

This is still an issue in F32.

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

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.

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.

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

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.

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

https://src.fedoraproject.org/rpms/java-11-openjdk/pull-request/124

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

This got stalled. But https://src.fedoraproject.org/rpms/java-11-openjdk/pull-request/129# rebased 124, was reviwed and is passing testing. Will be merged tomorrow, and multiplied to jdk8 and 17 and to live fedoras.
peter.org , all the gloty to you for the amazing idea with postrans, and sorry for delay.

Hello!

THis was merged to al jdks in fedora in August 2021.
It did its job well.

For record, it severely bitten back: https://bugzilla.redhat.com/show_bug.cgi?id=2001567