Bug 1260702 - order of scriplets is incorrect for reinstall
order of scriplets is incorrect for reinstall
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
24
Unspecified Unspecified
urgent Severity urgent
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1200302 1355687 1252406
  Show dependency treegraph
 
Reported: 2015-09-07 09:20 EDT by jiri vanek
Modified: 2016-07-12 05:06 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-12 05:06:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jiri vanek 2015-09-07 09:20:16 EDT
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)

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)
However, it is just making underlying issue visible, and being DNF/RPM I would be afraid when it will bite back.
Comment 1 Panu Matilainen 2015-10-24 06:23:29 EDT
(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 :)
Comment 2 jiri vanek 2015-10-26 06:01:13 EDT
> 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
Comment 3 Jan Kurik 2016-02-24 10:45:19 EST
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

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