Bug 1976053

The following one-liner is a temporary workaround to re-add the alternatives links after an update or reinstall:

rpm -qa --scripts java-{1.8.0,11}-openjdk-{headless,devel} | sed -n '/postinstall/, /exit/{ /postinstall/! { /exit/ ! p} }' | sh

(In reply to Peter Ajamian from comment #1)
> The following one-liner is a temporary workaround to re-add the alternatives
> links after an update or reinstall:
> 
> rpm -qa --scripts java-{1.8.0,11}-openjdk-{headless,devel} | sed -n
> '/postinstall/, /exit/{ /postinstall/! { /exit/ ! p} }' | sh

The real workaround is to do the reinstall second times. It will restore all what it needs. It is old issue, but wery hard to fix: https://bugzilla.redhat.com/show_bug.cgi?id=1200302

(In reply to jiri vanek from comment #2)
> (In reply to Peter Ajamian from comment #1)
> > The following one-liner is a temporary workaround to re-add the alternatives
> > links after an update or reinstall:
> > 
> > rpm -qa --scripts java-{1.8.0,11}-openjdk-{headless,devel} | sed -n
> > '/postinstall/, /exit/{ /postinstall/! { /exit/ ! p} }' | sh
> 
> The real workaround is to do the reinstall second times. It will restore all
> what it needs.

This is incorrect, if you run it twice, three times, twenty times it will never restore the links.  What happens is it actually installs the alternatives links and then removes them again in the same transaction, every time.

> It is old issue, but wery hard to fix:
> https://bugzilla.redhat.com/show_bug.cgi?id=1200302

Not hard to fix at all, and after reading through that entire thread I find it very disturbing that no one there proposed the very solution that is actually in the Fedora Packaging Guidelines:

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

Note the example postun section:

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

That's it, just wrap the alternatives --remove commands in if [ $1 -eq 0 ] ; then ... fi and they will only be run on an uninstall, not on a reinstall or update.  This works in rpm, dnf, yum, you name it.

Really, I find it amazing that this has come up and no one has proposed this very simple solution that was pretty much designed just to solve this exact problem!

just found this, it's been fixed in upstream Fedora, can we pull the fix into RHEL, please?

https://src.fedoraproject.org/fork/jgu/rpms/java-1.8.0-openjdk/c/276631960eff444b36862d024f126942accd095e

(In reply to Peter Ajamian from comment #3)
> (In reply to jiri vanek from comment #2)
> > (In reply to Peter Ajamian from comment #1)
> > > The following one-liner is a temporary workaround to re-add the alternatives
> > > links after an update or reinstall:
> > > 
> > > rpm -qa --scripts java-{1.8.0,11}-openjdk-{headless,devel} | sed -n
> > > '/postinstall/, /exit/{ /postinstall/! { /exit/ ! p} }' | sh
> > 
> > The real workaround is to do the reinstall second times. It will restore all
> > what it needs.
> 
> This is incorrect, if you run it twice, three times, twenty times it will
> never restore the links.  What happens is it actually installs the
> alternatives links and then removes them again in the same transaction,
> every time.

HAd just tried, and seesm you are correct. sorry.
> 
> > It is old issue, but wery hard to fix:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1200302
> 
> Not hard to fix at all, and after reading through that entire thread I find
> it very disturbing that no one there proposed the very solution that is
> actually in the Fedora Packaging Guidelines:
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
> 
> Note the example postun section:
> 
> %postun
> if [ $1 -eq 0 ] ; then
>   %{_sbindir}/update-alternatives --remove %{name} %{_bindir}/antlr-java
> fi
> 
> That's it, just wrap the alternatives --remove commands in if [ $1 -eq 0 ] ;
> then ... fi and they will only be run on an uninstall, not on a reinstall or
> update.  This works in rpm, dnf, yum, you name it.
> 
> Really, I find it amazing that this has come up and no one has proposed this
> very simple solution that was pretty much designed just to solve this exact
> problem!

Unluckily, we have intentionally moved from the snippet you quoted, to the current state of things, to support parallel install-ability.

(In reply to Peter Ajamian from comment #4)
> just found this, it's been fixed in upstream Fedora, can we pull the fix
> into RHEL, please?
> 
> https://src.fedoraproject.org/fork/jgu/rpms/java-1.8.0-openjdk/c/
> 276631960eff444b36862d024f126942accd095e

That is not upstream. That is jgu personal fork, which will cancel multiple packages to coexists. Fedora have same alternatives setup as have rhel. https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/blob/rawhide/f/java-1.8.0-openjdk.spec#_501

(In reply to jiri vanek from comment #6)
> (In reply to Peter Ajamian from comment #4)
> > just found this, it's been fixed in upstream Fedora, can we pull the fix
> > into RHEL, please?
> > 
> > https://src.fedoraproject.org/fork/jgu/rpms/java-1.8.0-openjdk/c/
> > 276631960eff444b36862d024f126942accd095e
> 
> That is not upstream. That is jgu personal fork, which will cancel multiple
> packages to coexists. Fedora have same alternatives setup as have rhel.
> https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/blob/rawhide/f/java-1.
> 8.0-openjdk.spec#_501

Yeah, I saw that in the spec, but it doesn't seem to contradict the advice or ability to wrap the removals in a conditional, and I fail to see how only running the removals if the package itself is actually being removed would affect parallel installs.  Do you have a link that explains that or that discusses new guidelines for this?

Is there any reason why this won't work:

%define postun_headless() %{expand:
  if [ "$1" -eq 0 ]; then
    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}}
  fi
}

(In reply to Peter Ajamian from comment #7)
> (In reply to jiri vanek from comment #6)
> > (In reply to Peter Ajamian from comment #4)
> > > just found this, it's been fixed in upstream Fedora, can we pull the fix
> > > into RHEL, please?
> > > 
> > > https://src.fedoraproject.org/fork/jgu/rpms/java-1.8.0-openjdk/c/
> > > 276631960eff444b36862d024f126942accd095e
> > 
> > That is not upstream. That is jgu personal fork, which will cancel multiple
> > packages to coexists. Fedora have same alternatives setup as have rhel.
> > https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/blob/rawhide/f/java-1.
> > 8.0-openjdk.spec#_501
> 
> Yeah, I saw that in the spec, but it doesn't seem to contradict the advice
> or ability to wrap the removals in a conditional, and I fail to see how only
> running the removals if the package itself is actually being removed would
> affect parallel installs.  Do you have a link that explains that or that
> discusses new guidelines for this?
> 
> Is there any reason why this won't work:
> 
> %define postun_headless() %{expand:
>   if [ "$1" -eq 0 ]; then
>     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}}
>   fi
> }


It is the reason I already hit - we support full version in install dir, and you can install unlimited number of openjdk rpms in parallel. It includes also fastdeug and slowdebug variants and any version, not only majoir (8,11,16) but also major (eg 8u292 and u302). Together with it it supports fluent upgrade and downgrade, and it was not easy to achieve with support from side of dnf prohibited. 
The paycost that the postunst is as it is and implication is broken reinstall. Here we know the fix, (see the https://bugzilla.redhat.com/show_bug.cgi?id=1200302 atachements), but that woudl be terrible maintenance burden.


Tbh, untill now  was pretty sure that second reisntall really is fixing the issue. If it is no  longer true, the issue would be worthy of revisiting. Thank you for report and sorry for troubles.

Looking into this more closely...

Okay, I see where you're going now.  A couple of suggestions:

1.  Use %{origin} and %{javaver} instead of %{version} and %{release}.  Especially don't use release, because this can work for updates as well, unless you are absolutely certain that updates will always run %postun of the old package before %post of the new (I wouldn't bet on that).

2.  Remove the temporary state file in a %posttrans scriptlet.  Once the dnf transaction is complete it isn't needed anymore and we should clean up our mess.

I realize that this solution isn't pretty, but I honestly think that breaking alternatives is worse, if a better solution comes along we can always switch to that, but this will do for now.

Oh, another idea to *really* simplify things.  Run the alternatives --install command in %posttrans instead of %post.  That way you are absolutely guaranteed that it will run after the remove in %postun.  then we don't have to jump through all these hoops.

(In reply to Peter Ajamian from comment #9)
> Looking into this more closely...
> 
> Okay, I see where you're going now.  A couple of suggestions:
> 
> 1.  Use %{origin} and %{javaver} instead of %{version} and %{release}. 
> Especially don't use release, because this can work for updates as well,

That would kill the paralel installability we have now.

> unless you are absolutely certain that updates will always run %postun of
> the old package before %post of the new (I wouldn't bet on that).
> 
> 2.  Remove the temporary state file in a %posttrans scriptlet.  Once the dnf
> transaction is complete it isn't needed anymore and we should clean up our
> mess.
> 
Yes. That is very similar to what the fix is doing in 1200302.

> I realize that this solution isn't pretty, but I honestly think that
> breaking alternatives is worse, if a better solution comes along we can

When second reinstall is no longer option, then yes, I definitely agree.

> always switch to that, but this will do for now.

(In reply to Peter Ajamian from comment #10)
> Oh, another idea to *really* simplify things.  Run the alternatives
> --install command in %posttrans instead of %post.  That way you are
> absolutely guaranteed that it will run after the remove in %postun.  then we
> don't have to jump through all these hoops.

That is quite interesting idea!

(In reply to jiri vanek from comment #11)
> (In reply to Peter Ajamian from comment #9)
> > Looking into this more closely...
> > 
> > Okay, I see where you're going now.  A couple of suggestions:
> > 
> > 1.  Use %{origin} and %{javaver} instead of %{version} and %{release}. 
> > Especially don't use release, because this can work for updates as well,
> 
> That would kill the paralel installability we have now.

I was under the impression reading the spec that %{javaver} needs to be unique for each install as it ends up becoming the unique part of the path to the parallel install, was I mistaken?

(In reply to Peter Ajamian from comment #13)
> (In reply to jiri vanek from comment #11)
> > (In reply to Peter Ajamian from comment #9)
> > > Looking into this more closely...
> > > 
> > > Okay, I see where you're going now.  A couple of suggestions:
> > > 
> > > 1.  Use %{origin} and %{javaver} instead of %{version} and %{release}. 
> > > Especially don't use release, because this can work for updates as well,
> > 
> > That would kill the paralel installability we have now.
> 
> I was under the impression reading the spec that %{javaver} needs to be
> unique for each install as it ends up becoming the unique part of the path
> to the parallel install, was I mistaken?

Javaver is 8,11,16... We suport parallel installs also of minors.

(In reply to jiri vanek from comment #12)
> (In reply to Peter Ajamian from comment #10)
> > Oh, another idea to *really* simplify things.  Run the alternatives
> > --install command in %posttrans instead of %post.  That way you are
> > absolutely guaranteed that it will run after the remove in %postun.  then we
> > don't have to jump through all these hoops.
> 
> That is quite interesting idea!

How would you know *what* to do in %posttrans? Posttrans is run once after the transaction. It's not package specific. Potentially you are removing 3 versions of a JDK and upgrading one, perhaps even installing one in addition. What alternatives do you install, which alternatives do you remove?

(In reply to Severin Gehwolf from comment #15)
> How would you know *what* to do in %posttrans? Posttrans is run once after
> the transaction. It's not package specific. Potentially you are removing 3
> versions of a JDK and upgrading one, perhaps even installing one in
> addition. What alternatives do you install, which alternatives do you remove?

I'm pretty certain that's incorrect.  %posttrans is run once for each package that defines it, but at the end of the transaction.  How could it be defined in the spec if it's not package-specific?  Also the docs suggest that it's run more than once in the suggestion here that if you want to ensure that it only runs once then you should set a flag file to make sure of that:

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

"If we only want the program in %posttrans to do its work once per-transaction, we may need to write out a flag file so that the %posttrans knows whether to perform an action."

...this suggests that if we don't set a flag file that the program could be run multiple times, hence it's not run just once per transaction.

%posttrans is never run for removal (only install/upgrade/reinstall) and the appropriate alternatives command will get hard-coded at the rpmbuild stage, basically put (how I understand it is that) each new package installed dumps it's %posttrans script into the queue to be run at the end of the transaction, so the %posttrans scriptlet for each individual rpm that is installed will contain the correct alternatives command to (re-)install the alternatives links for that particular rpm.

(In reply to Peter Ajamian from comment #16)
> (In reply to Severin Gehwolf from comment #15)
> > How would you know *what* to do in %posttrans? Posttrans is run once after
> > the transaction. It's not package specific. Potentially you are removing 3
> > versions of a JDK and upgrading one, perhaps even installing one in
> > addition. What alternatives do you install, which alternatives do you remove?
> 
> I'm pretty certain that's incorrect.  %posttrans is run once for each
> package that defines it, but at the end of the transaction.  How could it be
> defined in the spec if it's not package-specific?  Also the docs suggest
> that it's run more than once in the suggestion here that if you want to
> ensure that it only runs once then you should set a flag file to make sure
> of that:
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
> 
> "If we only want the program in %posttrans to do its work once
> per-transaction, we may need to write out a flag file so that the %posttrans
> knows whether to perform an action."
> 
> ...this suggests that if we don't set a flag file that the program could be
> run multiple times, hence it's not run just once per transaction.

I agree. Thanks for correcting me. It's been a while...

> %posttrans is never run for removal (only install/upgrade/reinstall) and the
> appropriate alternatives command will get hard-coded at the rpmbuild stage,
> basically put (how I understand it is that) each new package installed dumps
> it's %posttrans script into the queue to be run at the end of the
> transaction, so the %posttrans scriptlet for each individual rpm that is
> installed will contain the correct alternatives command to (re-)install the
> alternatives links for that particular rpm.

OK. The idea is to use %posttrans for installing alternatives and %postun to remove them. Do we know how %posttrans behaves if there are multiple versions of the same package in the transaction? Are they properly ordered? I guess this boils down to thorough testing (including the upgrade path) like was done for a prototype in bug 1200302 and then devise a plan for implementation. The devil is in the details. Thanks for your input!

Right. My understanding is that posttrans of each package  reinstalled/isntalled/updated/downgraded during transaction is run (at least) once after the trasnaction. I was not aware of possible additional runs, but that can be workaroudned by chekcing the slave is already here. If it is not package specific,then I would like to know how that is possible.

> OK. The idea is to use %posttrans for installing alternatives and %postun to
> remove them. Do we know how %posttrans behaves if there are multiple
> versions of the same package in the transaction? Are they properly ordered?

Does it meter?  In our case they will deal with one exact NVR anyway. And all posttrans will run after all postuns.

> I guess this boils down to thorough testing (including the upgrade path)

Yup. We shodl have pretty good coverage on those.

> like was done for a prototype in bug 1200302 and then devise a plan for
> implementation. The devil is in the details. Thanks for your input!

Indeed!

(In reply to jiri vanek from comment #19)
> > OK. The idea is to use %posttrans for installing alternatives and %postun to
> > remove them. Do we know how %posttrans behaves if there are multiple
> > versions of the same package in the transaction? Are they properly ordered?
> 
> Does it meter?  In our case they will deal with one exact NVR anyway. And
> all posttrans will run after all postuns.

It depends which alternative you want installed. Consider (provided proper pkg config):

$ yum install java-11-openjdk-11.0.11.0.9 java-11-openjdk-11.0.10.0.9

Do you want the corresponding JDK 11 alternative to be pointing to 11.0.11 or 11.0.10? I'm guessing they are properly order, but those are corner cases nobody really exercises much ;-)

(In reply to Severin Gehwolf from comment #20)
> (In reply to jiri vanek from comment #19)
> > > OK. The idea is to use %posttrans for installing alternatives and %postun to
> > > remove them. Do we know how %posttrans behaves if there are multiple
> > > versions of the same package in the transaction? Are they properly ordered?
> > 
> > Does it meter?  In our case they will deal with one exact NVR anyway. And
> > all posttrans will run after all postuns.
> 
> It depends which alternative you want installed. Consider (provided proper
> pkg config):
> 
> $ yum install java-11-openjdk-11.0.11.0.9 java-11-openjdk-11.0.10.0.9
> 
> Do you want the corresponding JDK 11 alternative to be pointing to 11.0.11
> or 11.0.10? I'm guessing they are properly order, but those are corner cases
> nobody really exercises much ;-)

that will be deterministically determined by priority on auto mode - always 11.0.10 will be there (if we count priority right), and left intact in manual mode.

(In reply to Severin Gehwolf from comment #20)
> (In reply to jiri vanek from comment #19)
> > > OK. The idea is to use %posttrans for installing alternatives and %postun to
> > > remove them. Do we know how %posttrans behaves if there are multiple
> > > versions of the same package in the transaction? Are they properly ordered?
> > 
> > Does it meter?  In our case they will deal with one exact NVR anyway. And
> > all posttrans will run after all postuns.
> 
> It depends which alternative you want installed. Consider (provided proper
> pkg config):
> 
> $ yum install java-11-openjdk-11.0.11.0.9 java-11-openjdk-11.0.10.0.9
> 
> Do you want the corresponding JDK 11 alternative to be pointing to 11.0.11
> or 11.0.10? I'm guessing they are properly order, but those are corner cases
> nobody really exercises much ;-)

that will be deterministically determined by priority on auto mode - always 11.0.11 will be there (if we count priority right), and left intact in manual mode.

I hit reload in very bad moment. - 11.0.11 will be there always, while we ocunt priorities right.

Assuming that each version has a different path to the linked files and we set the priority to the version number (or something akin to the version number) then the latest version should take precedence for the links, unless the user manually sets another one.  Also as long as we remove the same versioned links that we install then the scriptlets should just do the right thing.

Absolutely we should test this thoroughly.

(In reply to Peter Ajamian from comment #24)
> Assuming that each version has a different path to the linked files and we

That assumption is crrect

> set the priority to the version number (or something akin to the version
> number) then the latest version should take precedence for the links, unless

The  calcualtion f priority is pretty nasty, but autoamted and checked in specfile quite a lot.So should be ok.

> the user manually sets another one.  Also as long as we remove the same
> versioned links that we install then the scriptlets should just do the right
> thing.
>

As the https://bugzilla.redhat.com/show_bug.cgi?id=1200302 is against fedora, and I wills tart with PR to fedora, I will continue there.

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.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (java-1.8.0-openjdk bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1775

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days