[External] : Re: RFR: 8350594: Misleading warning about install dir for DMG packaging

[Alexey Semenyuk]

On 3/4/2025 11:06 AM, Michael Hall wrote:
>> Good point about `CFBundleGetInfoString`. Maybe jpackage should set this field with the value of `--description` option. Another finding!
>>
>> As for editing "Info.plist" from the runtime source, if the directory referenced from `--runtime-image` option is a valid bundle, i.e. has "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, and there are no other options, like `--app-version`, jpackage should use the supplied directory as-is without editing the existing "Info.plist" file. Otherwise, jpackage should create "Info.plist" and make sure the values are consistent, of course.
> I posted an example, there are a few other places in Info.plist that would also need changing to the correct version if you don’t already have a valid Info.plist for the JRE. The page of mine that you linked I think mentioned them all.
>
>   __CodeSignature I didn’t include in what I did. It seemed like you might not be able to copy this but would need to do your own signing to generate it for a different JRE? My guess was that it is only really needed for an application distribution including that JRE. I know jpackage does some of its own signing. If this recreates the JRE __CodeSignature, this probably wouldn’t be a concern.
>
> It is possible if you are provided with a JRE where all this is correct then copying as-is would be fine.
Right. If you package unpacked official OpenJDK tar.gz jpackage should 
take it as is.

> However, if you are copying a JRE that already has a JavaVirtualMachines file for that version I’m not sure what would happen.
The same as in the above case, I guess. jpackage should take it as is.

> That should be checked? If you are providing a later release the new one should be used.
Sorry, I don't follow. What release do you mean?

> If you are providing an earlier release the one you are adding will be ignored. Warnings at least? /usr/libexec/java_home -v <target.version> could maybe be useful here. I think though you would need to determine the version of what you are copying in.
>
> Assuming the JRE you are adding to JavaVirtualMachines is a unique or current one for that java version then I think some fairly simple test like java —version or something again with /usr/libexec/java_home could verify that everything is alright.
jpackage doesn't control how you use bundles it produces. You can use 
the same input runtime image and create two separate bundles with 
different names, but with the same versions and install them both.

- Alexey
>