Well, it's easy to tell what the issue is: RHEL 7's java-11-openjdk*/conf is a directory, while RHEL 8's is a symlink.

The question is how to fix this. The %pretrans part of the RPM that handles this is outsourced to the copy-jdk-configs script, so I'm reassigning the bug there. I suspect a check for conf being a directory is required, and to remove it if so, before the RPM installation stage runs.

hi!

I'm not sure this is error in our lua script or copy-jdk-configs pacakage.

This is known limitation of RPM. rpm is not able to upgrade package, where a directory changes to symlink. Thus in fedora we can do that only with new jdk, and in rhel we can do it only with new major version of rhel.

I'm afraid this is have to be solved in leap. Not in rpm, not in jdk, not in cop-jdk-configs.

It's possible to deal with that in %pretrans. See:
- https://fedoraproject.org/wiki/Packaging:Directory_Replacement#Replacing_a_symlink_with_a_directory_or_a_directory_with_any_type_of_file
- https://bugzilla.redhat.com/show_bug.cgi?id=1703117

The java-11-openjdk-headless package is currently the only package that Leapp removes before the upgrade, in order to be able to upgrade the system: https://github.com/oamg/leapp-repository/pull/484.
The Leapp team will remove it from the "blacklist" as soon as the spec is fixed and shipped to public CDN.

(In reply to Michal Bocek from comment #3)
> It's possible to deal with that in %pretrans. See:
> -
> https://fedoraproject.org/wiki/Packaging:
> Directory_Replacement#Replacing_a_symlink_with_a_directory_or_a_directory_wit
> h_any_type_of_file
> - https://bugzilla.redhat.com/show_bug.cgi?id=1703117
> 
> The java-11-openjdk-headless package is currently the only package that
> Leapp removes before the upgrade, in order to be able to upgrade the system:
> https://github.com/oamg/leapp-repository/pull/484.
> The Leapp team will remove it from the "blacklist" as soon as the spec is
> fixed and shipped to public CDN.

I know that. I even posted that link to you via emails.
However jdk is NOT going to be fixed in that way, because we are doing much more dark magic with that config dir due to paralell install-ability feature.  Please workaorund it in leapp

If you need Leapp to handle this particular issue instead of fixing it in the rpm spec, then we need you, the Java RHEL subsystem, to create a module(s) for that in Leapp. We call the Leapp modules "actors". Here's a guide on creating Leapp actors: https://leapp.readthedocs.io/en/latest/el7toel8/actor-rhel7-to-rhel8.html.
If there's any issue or you need to consult something, just ping mbocek or pstodulk on the internal IRC channel #leapp. Or write to the leapp-devel mailing list. We'll try to help/guide you.

Would it be simpler to fix this locally in the RHEL 8 OpenJDK packages that need it, rather than in copy-jdk-configs?
The code Michal linked to looks easy enough to add to those packages, and making leapp work around it doesn't solve the problem for customers moving from RHEL 7 to RHEL 8.

It would be good to know how to easily reproduce this. The original report doesn't give much detail. Thanks.

(In reply to Andrew John Hughes from comment #6)
> Would it be simpler to fix this locally in the RHEL 8 OpenJDK packages that
> need it, rather than in copy-jdk-configs?
> The code Michal linked to looks easy enough to add to those packages, and
> making leapp work around it doesn't solve the problem for customers moving
> from RHEL 7 to RHEL 8.
> 
> It would be good to know how to easily reproduce this. The original report
> doesn't give much detail. Thanks.

Yes, we have to fix it in rhel8 packages,
The issue is, the lua script is sourced here.
So in internal spec lua script, we have to use the snipped I linked, and the source copy jdk configs. That is wy  was reluctant to do it as first option. Obviously, there is not much more options.

(In reply to jiri vanek from comment #9)
> (In reply to Andrew John Hughes from comment #6)
> > Would it be simpler to fix this locally in the RHEL 8 OpenJDK packages that
> > need it, rather than in copy-jdk-configs?
> > The code Michal linked to looks easy enough to add to those packages, and
> > making leapp work around it doesn't solve the problem for customers moving
> > from RHEL 7 to RHEL 8.
> > 
> > It would be good to know how to easily reproduce this. The original report
> > doesn't give much detail. Thanks.
> 
> Yes, we have to fix it in rhel8 packages,
> The issue is, the lua script is sourced here.
> So in internal spec lua script, we have to use the snipped I linked, and the
> source copy jdk configs. That is wy  was reluctant to do it as first option.
> Obviously, there is not much more options.

Will such a change break anything? If we can make rhel7-rhel8 upgrades smoother, I am all for it assuming it does not introduce any instability.

(In reply to Deepak Bhole from comment #10)
> (In reply to jiri vanek from comment #9)
> > (In reply to Andrew John Hughes from comment #6)
> > > Would it be simpler to fix this locally in the RHEL 8 OpenJDK packages that
> > > need it, rather than in copy-jdk-configs?
> > > The code Michal linked to looks easy enough to add to those packages, and
> > > making leapp work around it doesn't solve the problem for customers moving
> > > from RHEL 7 to RHEL 8.
> > > 
> > > It would be good to know how to easily reproduce this. The original report
> > > doesn't give much detail. Thanks.
> > 
> > Yes, we have to fix it in rhel8 packages,
> > The issue is, the lua script is sourced here.
> > So in internal spec lua script, we have to use the snipped I linked, and the
> > source copy jdk configs. That is wy  was reluctant to do it as first option.
> > Obviously, there is not much more options.
> 
> Will such a change break anything? If we can make rhel7-rhel8 upgrades
> smoother, I am all for it assuming it does not introduce any instability.

I dont know. I created an patch (currenlty not tested).  Really hard to judge consequences.

Created attachment 1683327 [details]
first version of patch to deal with transition

Note that the patch intentionally do not handel debug subpackages, whcih we do not ship via standart channels.

Created PR, https://src.osci.redhat.com/rpms/java-11-openjdk/pull-request/20 , am wondering how the build passes and what hte result will do...

ok. the patch do not work. Becausde by this.we are changing the files in *current* jdk, not in already intstalled ones (cursed be multiple installs!)

So another approach on this logic must be taken. Old JDK must be found first:(

i have updated the PR to try the symlink

The symlink approach moreover works. Now I'm trying to figure out, if we can do better. Afaik yes, because the original fedora scriplet is for packages not supporting parale-insallability (of course).

Next to   directrory NVR1/conf we add symlink NVR2/conf . However copy jdk configs copies the  directory of NVR1/conf to NVR2/conf to actually prettend that we do an override.

hi!

We have patch ready to fix this, and it is working as expected. (see PR)

There is small glitch with user experience, which is however expected as by fedora guidelines:

user have configs in /usr/lib/jvm/java-11-openjdk-VR1/conf directory.

Fedora guidelines are enforcing to backup this directory by mv before it is "repalced by symlink". So after update

user new have configs in /usr/lib/jvm/java-11-openjdk-VR2/conf symlink and old configs are stored in  /usr/lib/jvm/java-11-openjdk-VR2/conf.rpmmoved directory
/usr/lib/jvm/java-11-openjdk-VR1/ is removed properly.

Is it expected that user shold manually visit theirs configs?

All our configs are config(norepalce) so during usual updates of JDK, the user is expected to got not repalced his customised configs.

This can be additionally fixed in lua scriplet, but the scriplet is complicated already enough,

Tried the upgrade using:

java-11-openjdk-11.0.8.1-0.0.ea.0.pr.1ade216037d44afe9a06ed036dad7dc9.c.11948.el8_2.x86_64
java-11-openjdk-headless-11.0.8.1-0.0.ea.0.pr.1ade216037d44afe9a06ed036dad7dc9.c.11948.el8_2.x86_64

and it passed.

https://src.osci.redhat.com/rpms/java-11-openjdk/pull-request/26

Jiri, how controversial is the change? Is there a risk that things could break? If the fix is safe, I am +1 for putting it in 8.2 EUS

(In reply to Deepak Bhole from comment #35)
> Jiri, how controversial is the change? Is there a risk that things could
> break? If the fix is safe, I am +1 for putting it in 8.2 EUS

The first version was. Thats when the need info was raised.  In meantime I realised it can be done better. Second version of patch should be not controversial at all.

Deepak or Jiri, please clone this BZ to introduce the fix to 8.2 EUS. Thanks.

Michal, do we want 8.1.0 as well? If I recall correctly, I've been hitting this leapp failure on every RHEL 8 version but RHEL 8.0.0.

Let me know and I'll make the appropriate clones.

Thank you. 8.1.0 is not needed. At least not because of upgrades because upgrades to 8.1 are not supported anymore.

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-11-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-2020:4657