On Wed, 26 Mar 2025 10:12:43 GMT, Alan Bateman <[email protected]> wrote:
> > The cacerts issue mentioned in the JBS issue relates to an RPM installation
> > of the JDK where the cacerts file is a symlink to the distro provided one.
> > So I think that's "use system" issue.
> > TZ updates would potentially break this too. If an external tool updates
> > `tzdb.dat` then the hash sum computed at JDK build-time will no longer
> > match. I believe this could also be solved with a sha-override (e.g. by
> > coming from a file `@${java.home}/sha-override.txt`) which would get the
> > update along with `tzdb.dat`.
>
> I think one direction to explore is configuring which files or directory are
> "upgradable". Upgradable modules aren't excluded from the hash computation to
> allow upgrade via the upgrade module path. Something similar here would allow
> jlink to report that tzdb.dat has been upgraded. Maybe cacerts is the same
> but need to look closer as the hash computation shouldn't be following sym
> links outside of the runtime image.
I'll keep looking into this specific case. However, it sounds a bit orthogonal
to the patch at hand which I do believe we still need for the original reasons
mentioned (RPM changing binaries after the JDK build is long done and the
windows issue of the JDK build itself placing different *.pdb files into the
image than was present at jlink time). So perhaps we should explore this in
parallel?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24190#issuecomment-2754680306
