Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1355687 - dnf reinstall breaks alternatives
Summary: dnf reinstall breaks alternatives
Keywords:
Status: CLOSED DUPLICATE of bug 1200302
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On: 1260702
Blocks: 1200302
TreeView+ depends on / blocked
 
Reported: 2016-07-12 09:03 UTC by jiri vanek
Modified: 2018-06-29 13:26 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1200302
Environment:
Last Closed: 2018-06-29 13:26:19 UTC


Attachments (Terms of Use)

Description jiri vanek 2016-07-12 09:03:18 UTC
+++ This bug was initially created as a clone of Bug #1200302 +++

Description of problem:
As a side effect of other problems with dnf I had to reinstall few packages.
After this action I was not able to use java related applications (e.g. eclipse)
It took me few hours to find a root of all evil.

dnf reinstall broke my alternatives and therefore java was removed from alternatives.

Version-Release number of selected component (if applicable):
sh$ rpm -q python3-dnf dnf
python3-dnf-0.6.4-2.fc22.noarch
dnf-0.6.4-2.fc22.noarch

How reproducible:
Deterministic

Steps to Reproduce:
1. dnf-3 install java-1.8.0-openjdk-headless
3. dnf-3 reinstall java-1.8.0-openjdk-headless


Actual results:
[root@host ~]# java -version
-bash: java: command not found

[root@host ~]# update-alternatives --display java
[root@host ~]# echo $?
2

Expected results:
[root@host ~]# java -version
openjdk version "1.8.0_40"
OpenJDK Runtime Environment (build 1.8.0_40-b12)
OpenJDK 64-Bit Server VM (build 25.40-b16, mixed mode)

[root@host ~]# update-alternatives --display java
java - status is auto.
 link currently points to /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/java
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/java - priority 1800040
 slave jre: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre
 slave jre_exports: /usr/lib/jvm-exports/jre-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64
 slave jjs: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/jjs
 slave keytool: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/keytool
 slave orbd: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/orbd
 slave pack200: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/pack200
 slave rmid: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/rmid
 slave rmiregistry: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/rmiregistry
 slave servertool: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/servertool
 slave tnameserv: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/tnameserv
 slave unpack200: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/unpack200
 slave java.1.gz: /usr/share/man/man1/java-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
 slave jjs.1.gz: /usr/share/man/man1/jjs-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
 slave policytool: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/policytool
 slave keytool.1.gz: /usr/share/man/man1/keytool-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
 slave orbd.1.gz: /usr/share/man/man1/orbd-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
 slave pack200.1.gz: /usr/share/man/man1/pack200-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
 slave rmid.1.gz: /usr/share/man/man1/rmid-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
 slave rmiregistry.1.gz: /usr/share/man/man1/rmiregistry-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
 slave servertool.1.gz: /usr/share/man/man1/servertool-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
 slave tnameserv.1.gz: /usr/share/man/man1/tnameserv-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
 slave unpack200.1.gz: /usr/share/man/man1/unpack200-java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64.1.gz
Current `best' version is /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64/jre/bin/java

Additional info:
A workaroud for this bug is to reinstall package with yum.

--- Additional comment from Jan Silhan on 2015-03-24 07:14:21 EDT ---

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

--- Additional comment from Lukas Slebodnik on 2015-03-24 07:23:07 EDT ---

Thank you for info.

If the bug is not in dnf then please reassign to correct component java-1.8.0-openjdk-headless or provide fix to java spec files.

I don't mind where it will be fixed.

--- Additional comment from Lukas Slebodnik on 2015-05-04 17:27:59 EDT ---

dnf-yum redirected yum to dnf.

As I mentions in the description of bug, it works with yum(yum-depreceated)
but not with dnf. It would be good to either fix it in dnf or fix java packaging.

Is there any progress with this BZ?

--- Additional comment from Fedora Blocker Bugs Application on 2015-05-08 07:55:08 EDT ---

Proposed as a Blocker for 22-final by Fedora user lslebodn using the blocker tracking app because:

 /usr/bin/yum is part of dnf-yum and it calls dnf under hood.
Re-installation of java package causes dis-functional java and many popular IDEs will not start.

It works with yum (yum-deprecated) so it is a regression caused by dnf-yum.

--- Additional comment from Dan Mossor [danofsatx] on 2015-05-11 15:28:23 EDT ---

Discussed at the 2015-05-11 blocker review meeting[0]. Voted as RejectedBlocker.

#agreed 1200302 - RejectedBlocker - this bug obviously sucks if you run into it, but doesn't seem especially critical to the release media, doesn't violate any release criteria, and seems unlikely to be hit very often

[0]: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-11/

--- Additional comment from Jan Silhan on 2015-07-21 05:49:06 EDT ---

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

--- Additional comment from jiri vanek on 2015-07-21 07:40:56 EDT ---

Hi!

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

What is this ts.addReinstall

--- Additional comment from jiri vanek on 2015-08-11 08:28:43 EDT ---



--- Additional comment from Deepak Bhole on 2015-08-11 16:23:31 EDT ---

Adding NEEDINFO based on comment #7

--- Additional comment from jiri vanek on 2015-08-13 03:50:12 EDT ---

(In reply to Jan Silhan from comment #1)
> Thanks for the report. Probably wrong scriplets. DNF uses the
> `ts.addReinstall` rpm method in contrast to yum.

Are you pointing to this api?
yum.baseurl.org/api/yum-3.2.27/yum.transactioninfo.TransactionData-class.html

If so, why dnf changedt it from yum's original schmema?

--- Additional comment from Jan Silhan on 2015-08-14 09:03:29 EDT ---

I am not able to reproduce it. It works for me. Is it possible it's fixed in 1.8.0_51?

# sudo dnf reinstall java-1.8.0-openjdk-headless -y
...
java -version
openjdk version "1.8.0_51-debug"
OpenJDK Runtime Environment (build 1.8.0_51-debug-b16)
OpenJDK 64-Bit Server VM (build 25.51-b03-debug, mixed mode)

(In reply to jiri vanek from comment #10)
> (In reply to Jan Silhan from comment #1)
> > Thanks for the report. Probably wrong scriplets. DNF uses the
> > `ts.addReinstall` rpm method in contrast to yum.
> 
> Are you pointing to this api?
>
> If so, why dnf changedt it from yum's original schmema?

This is the difference [1] from yum (the same it used to be in DNF). The change was made because of bug 1071854.

[1] https://github.com/rpm-software-management/dnf/commit/516aad977e108df0f99c0bfc03a25b180888937f

--- Additional comment from Heldwin on 2015-08-14 09:39:21 EDT ---

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

--- Additional comment from Heldwin on 2015-08-14 09:48:26 EDT ---

dnf-1.1.0-2.fc22.noarch
dnf-plugins-core-0.1.10-1.fc22.noarch
python-dnf-1.1.0-2.fc22.noarch
hawkey-0.6.0-1.fc22.x86_64
python-hawkey-0.6.0-1.fc22.x86_64

just a reinstall didn't correct the java path, so I removed it and installed it again to see. It found java again, but then a reinstall made it loose it again.

--- Additional comment from Heldwin on 2015-08-15 10:11:36 EDT ---



--- Additional comment from Heldwin on 2015-08-15 10:15:24 EDT ---

if I use:

rpm -Uvh --force rpm -Uvh --force java-1.8.0-openjdk-headless-1.8.0.51-4.b16.fc22.x86_64.rpm

or: yum-deprecated reinstall java-1.8.0-openjdk-headless

after the system cannot find java, it then can find it.

If I reinstall with dnf, and then run the commands in attachment 1063275 [details], it also can find the java command again.

--- Additional comment from Heldwin on 2015-08-15 10:17:17 EDT ---

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

--- Additional comment from Roger Wells on 2015-09-03 16:22:08 EDT ---

I can confirm this.
Thanks to everyone who tracked it down.
The breaking of alternatives is very serious in those cases where a 32 bit java alternative is needed.  An example might be Juniper Network's VPN which is much used in our office.

--- Additional comment from jiri vanek on 2015-09-04 06:33:21 EDT ---

After some digging this is what I see:

Previous behaviour of dnf/rpm was:
compelte erase of package (including its postuns)
again istalling of package (including its posts)

Now the behaviour is like update - http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering

pre of package
removal
install
post of package


In case of openjdk, in post, we are removing what we added in pre. And it is quite necessary. Imho any scenario running POST after PRE do nto have sense...

I'm inclining to move this bug to RPM (dnf?) again...

--- Additional comment from jiri vanek on 2015-09-04 06:35:44 EDT ---

I swapped pre with post and post with postu
fix:

post of package
removal
install
postU of package


In case of openjdk, in post, we are removing what we added in pre. And it is quite necessary. Imho any scenario running POSTU after POST do nto have sense...

--- Additional comment from Jan Silhan on 2015-09-04 07:50:08 EDT ---

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

--- Additional comment from jiri vanek on 2015-09-04 08:24:54 EDT ---

I made typo in above c#18. As c#19 was  unclear explanation, here it is again:


After some digging this is what I see:

Previous behaviour of dnf/rpm was:
compelte erase of package (including its postuns)
again istalling of package (including its posts)

Now the behaviour is like update - http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering

post of package
removal
install
postun of package


In case of openjdk, in postun, we are removing what we added in post. And it is quite necessary. Imho any scenario running POSTUN after POST do not have sense...

I'm inclining to move this bug to RPM (dnf?) again...

--- Additional comment from Severin Gehwolf on 2015-09-09 12:25:56 EDT ---

(In reply to Jan Silhan from comment #20)
> Florian, is there any reason for this ^ scriplet execution order? In update
> it could make sense but in reinstall it's a little confusing.

[1] and [2] seem to answer this question, no? Since new dnf uses rpm's --reinstall that's the expected order.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1071854#c8
[2] https://bugzilla.redhat.com/show_bug.cgi?id=966715#c7

--- Additional comment from jiri vanek on 2015-09-10 04:35:33 EDT ---

(In reply to Severin Gehwolf from comment #22)
> (In reply to Jan Silhan from comment #20)
> > Florian, is there any reason for this ^ scriplet execution order? In update
> > it could make sense but in reinstall it's a little confusing.
> 
> [1] and [2] seem to answer this question, no? Since new dnf uses rpm's
> --reinstall that's the expected order.

Well, yes - expected - But have this order sense[3] for reinstall?

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1071854#c8
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=966715#c7

[3] https://bugzilla.redhat.com/show_bug.cgi?id=1260702

--- Additional comment from Severin Gehwolf on 2015-09-10 09:53:56 EDT ---

(In reply to jiri vanek from comment #23)
> (In reply to Severin Gehwolf from comment #22)
> > (In reply to Jan Silhan from comment #20)
> > > Florian, is there any reason for this ^ scriplet execution order? In update
> > > it could make sense but in reinstall it's a little confusing.
> > 
> > [1] and [2] seem to answer this question, no? Since new dnf uses rpm's
> > --reinstall that's the expected order.
> 
> Well, yes - expected - But have this order sense[3] for reinstall?

Yes it makes sense to me. Considering bug 966715 there seem to be use cases where package re-installations may be done with different flags. In the bug --nodocs is the example. If re-install didn't remove docs first, docs would still be installed after re-install. Something similar is conceivable for files added during post/postun. For example RPM state files. [I] might be an example. [II] has more realistic examples it seems. Either way it's conceivable that %post creates a file/symlink/whatever %postun removes them.

[I] https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Saving_state_between_scriptlets
[II] http://rpm.org/api/4.4.2.2/triggers.html

--- Additional comment from Severin Gehwolf on 2015-09-10 10:04:14 EDT ---

For the record, the reproducer for this bug is either "rpm --reinstall":

$ rpm -q java-1.8.0-openjdk
java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64
$ dnf download java-1.8.0-openjdk{,-devel,-headless}
$ java -version; sudo rpm --reinstall java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64.rpm java-1.8.0-openjdk-devel-1.8.0.60-14.b27.fc22.x86_64.rpm java-1.8.0-openjdk-headless-1.8.0.60-14.b27.fc22.x86_64.rpm; java -version
openjdk version "1.8.0_60"
OpenJDK Runtime Environment (build 1.8.0_60-b27)
OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode)
-bash: /usr/bin/java: No such file or directory

Or "dnf reinstall":

$ java -version; sudo dnf reinstall java-1.8.0-openjdk{,-devel,-headless} > /dev/null 2>&1; java -version
openjdk version "1.8.0_60"
OpenJDK Runtime Environment (build 1.8.0_60-b27)
OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode)
-bash: /usr/bin/java: No such file or directory

It makes sense to me that rpm and dnf is consistent.

--- Additional comment from Severin Gehwolf on 2015-09-10 10:06:17 EDT ---

(In reply to Severin Gehwolf from comment #24)
> (In reply to jiri vanek from comment #23)
> > (In reply to Severin Gehwolf from comment #22)
> > > (In reply to Jan Silhan from comment #20)
> > > > Florian, is there any reason for this ^ scriplet execution order? In update
> > > > it could make sense but in reinstall it's a little confusing.
> > > 
> > > [1] and [2] seem to answer this question, no? Since new dnf uses rpm's
> > > --reinstall that's the expected order.
> > 
> > Well, yes - expected - But have this order sense[3] for reinstall?
> 
> Yes it makes sense to me. Considering bug 966715 there seem to be use cases
> where package re-installations may be done with different flags. In the bug
> --nodocs is the example. If re-install didn't remove docs first, docs would
> still be installed after re-install. Something similar is conceivable for
> files added during post/postun. For example RPM state files. [I] might be an
> example. [II] has more realistic examples it seems. Either way it's
> conceivable that %post creates a file/symlink/whatever %postun removes them.
> 
> [I]
> https://fedoraproject.org/wiki/Packaging:
> ScriptletSnippets#Saving_state_between_scriptlets
> [II] http://rpm.org/api/4.4.2.2/triggers.html

One more thing:
https://bugzilla.redhat.com/show_bug.cgi?id=966715#c5 seems to suggest "rpm --reinstall" behaving like an update is by design.

--- Additional comment from Severin Gehwolf on 2015-09-10 10:24:47 EDT ---

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

--- Additional comment from jiri vanek on 2015-09-10 10:36:13 EDT ---

Thats pretty terrible, isnt it?
Even if it would notbe terrible by nature, then it will need to go to all javas in rhel8 - 3x  oracle, 3x openjdk  and 3x ibm. And keep telling another maintainers why it is here.

I'm spending quite a lot of time to remove the terrible workarounds we have in spec by tweeking alternatives, rpm plugins and yum is in queue.
Now - for tool of our future - dnf - I will need to add another hack?

I simply cant accept this.  And I quite insists that *soemthing* is wrong.
The only workaround I'm willing to accept is, that http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax will be enhanced for reinstall column.
And even then it will be still "wrong by design"  (c#26).
I'm not saying the idea itself is wrong. But it is not finished in manner of 1260702

With every chnage in underlying tools, Some workaround was added to specfiles, until they grow to current state. So for future tool of future packages this is no go.

--- Additional comment from jiri vanek on 2016-02-29 03:58:36 EST ---

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

--- Additional comment from Adam Buraczewski on 2016-07-11 08:11:39 EDT ---

I would like to confirm this bug for dnf 1.1.9 and OpenJDK 1.8.0.92 in Fedora 24.  Reinstalling OpenJDK packages causes all java-related symlinks from /usr/bin, /usr/lib/jvm and /etc/alternatives to disappear.  The only method of fixing them back is using "yum-deprecated reinstall" command.

Comment 1 jiri vanek 2016-07-12 09:07:50 UTC
Hello!

I cloned this bug, because itneeds fixes both in dnf(rpm?) and openjdk.

When read the

Comment 2 jiri vanek 2016-07-12 09:11:35 UTC
Hello!

I cloned this bug

Comment 3 jiri vanek 2016-07-12 09:16:04 UTC
(sorry, pressed submit in middle of sentence) 
Hello!

I cloned this bug, because this si not fixable in openjdk itself. 

When I re-read the bugs of 1260702 and 1200302 the only moreover acceptable solution is  to make scriplets aware that it is reinstall.

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

 	install 	upgrade 	uninstall       *reinstall*
 %pretrans 	$1 == 0 	$1 == 0 	(N/A)      $1==3 or $2==1
 %pre 	$1 == 1 	$1 == 2 	(N/A)              $1==3 or $2==1
 %post 	$1 == 1 	$1 == 2 	(N/A)              $1==3 or $2==1
 %preun 	(N/A) 	$1 == 1 	$1 == 0            $1==3 or $2==1
 %postun 	(N/A) 	$1 == 1 	$1 == 0            $1==3 or $2==1
 %posttrans 	$1 == 0 	$1 == 0 	(N/A)      $1==3 or $2==1

Or something  similar.


Then I can fix openjdk packages, so on reinstall, the scrippelts will be abel to act.

Comment 4 Igor Gnatenko 2016-07-12 09:18:36 UTC
we use RPM's reinstall(), so DNF has nothing to do with this

Comment 5 Fedora End Of Life 2017-07-25 21:45:12 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 6 Fedora End Of Life 2018-05-03 08:17:34 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 7 jiri vanek 2018-05-03 08:56:04 UTC
still alive

Comment 8 Panu Matilainen 2018-06-29 13:26:19 UTC

*** This bug has been marked as a duplicate of bug 1200302 ***


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