(In reply to jiri vanek from comment #0)
> When change of
> https://bugzilla.redhat.com/show_bug.cgi?id=1200302#c1
> by code of 
> https://bugzilla.redhat.com/show_bug.cgi?id=1200302#c11
> or directly 
> https://github.com/rpm-software-management/dnf/commit/
> 516aad977e108df0f99c0bfc03a25b180888937f
> 
> Was applied, the schema of reinstall moved from
>   complete erase
>   fresh install
> to update-like
>   install
>   remove
> The reason was https://bugzilla.redhat.com/show_bug.cgi?id=1071854 and
> fixation of corrupted files (when rewriting on them works, but not removal
> if I got it right)

Nope. Prior to the change, there was no erasure whatsoever taking place. So the change was from:
   write files to disk
to update-like
   install
   remove

> 
> However I agree with the change, there is serious flaw of invalid scriplet
> ordering. The bug is visible via
> https://bugzilla.redhat.com/show_bug.cgi?id=1200302
> Its happening, becasue openjdk have each scriplet bounded to version:
> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-
> openjdk.spec?id=8cd6f461c6a8895263c142e94a800f066c8aea2b#n262 and this
> scripplet MUST be run during both update and install/removal.
> 
> By the change, the whole process changed from
>   remove
>   postu
>   install
>   post
> 
> to -
> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering
>   install
>   post
>   remove
>   postu
> 
> Which is - on first sight incorrect. Reinstal is now running POSTU of same
> version of package after its POST
> anything else, like
>   install
>   remove
>   postu
>   post
> or even (which I consider as best, as current update like process is not an
> reinstall)
>   install
>   post
>   remove
>   postu
>   install
>   post
> 
> The DNF/RPM is now doing something unexpected for post/postu. 
> 
> In normal update you have two versions of scriplets involved
> (deep past)
>   install X.Y
>   post    X.Y
> --------------
>   install X.Z
>   post    X.Z
>   remove  X.Y
>   postu   X.Y
> 
> But in reinstall the SAME version appear
> (deep past)
>   install X.Y
>   post    X.Y
> --------------
>   install X.Y
>   post    X.Y //possible clash?
>   remove  X.Y
>   postu   X.Y //clean up after itself?
> 
> postu of X.Y is designed to cleanup after post of X.Y so by invoking
> immidiately after post, it is moreover discardingits work, while keeping
> package it installed (unike normla update, where it removes post of previous
> pacakge and discards it while keeps newest package installed and its post in
> place)
> 
> One final nit - The failure of jdk packages at 1200302 is consequence of
> this change. May be hard to fix, but fixable. (as with current ordering it
> have to be exected during install, update and removal, but not during
> reinstall)

I didn't look too carefully, but the lack of update detection seems suspicious to me, eg:

%global postun_headless() %{expand:
  alternatives --remove java %{jrebindir %%1}/java
  alternatives --remove jre_%{origin} %{_jvmdir}/%{jredir %%1}
  alternatives --remove jre_%{javaver} %{_jvmdir}/%{jredir %%1}
  alternatives --remove jre_%{javaver}_%{origin} %{_jvmdir}/%{jrelnk %%1}
}

Shouldn't you only remove these when $1 is zero? Hmm, guess it has to do with all those paths having full NEVRA enconded in them so you're actually expecting them to *always* change, which by design is at odds with reinstall the way rpm has to do it.

> However, it is just making underlying issue visible, and being DNF/RPM I
> would be afraid when it will bite back.

Its not possible to perform erase then install in the general case. Think about what would happen with reinstall of, say, glibc in that case. Reinstall always was a fishy operation, previously completely broken, now "only" fishy :)

> Nope. Prior to the change, there was no erasure whatsoever taking place. So
> the change was from:
>    write files to disk

 Oh....  But that was incredibly super cool and mega powerfull. But I read the bug why it was ...foxed..eee.changed. to:

> to update-like
>    install
>    remove
> 
> > 

this.
...
> 
> I didn't look too carefully, but the lack of update detection seems
> suspicious to me, eg:
> 
> %global postun_headless() %{expand:
>   alternatives --remove java %{jrebindir %%1}/java
>   alternatives --remove jre_%{origin} %{_jvmdir}/%{jredir %%1}
>   alternatives --remove jre_%{javaver} %{_jvmdir}/%{jredir %%1}
>   alternatives --remove jre_%{javaver}_%{origin} %{_jvmdir}/%{jrelnk %%1}
> }
> 
> Shouldn't you only remove these when $1 is zero? Hmm, guess it has to do

No. It is easy to overlook,  but java have quite unique behaviour here.those jre* dirs are whole  NVRA - so they are removed and added intentionally. I add NVRA+1 and remove NVRA 

(see eg https://github.com/lnykryn/chkconfig/  initiative to help us a bit)



> with all those paths having full NEVRA enconded in them so you're actually
> expecting them to *always* change, which by design is at odds with reinstall
> the way rpm has to do it.
> 
> > However, it is just making underlying issue visible, and being DNF/RPM I
> > would be afraid when it will bite back.
> 
> Its not possible to perform erase then install in the general case. Think
> about what would happen with reinstall of, say, glibc in that case.
> Reinstall always was a fishy operation, previously completely broken, now
> "only" fishy :)


Seeing the discusion. I think the only way is to add reisntall flag among 
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax

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

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase