Score:2

How to enforce a package dependency instead of an alternative?

cn flag

I am developing a Debian package for Ubuntu which uses Java 17. We have historically had a runtime dependency on openjdk-17-jre. We have a part of our software that has used JavaFX on Windows and macOS for the web browser component. We have disabled this page on Linux since OpenJDK doesn't include JavaFX. I finally figured out how to include openjfx and libopenjfx-jni and then modify our startup script to pass the correct parameters to Java. Here are the dependencies in my debian/control file:

Depends: openjdk-17-jre, xdg-utils, openjfx, libopenjfx-jni

This has worked fine for most users. However, we have users that also have bellsoft-java17-full installed for other software. When the source for bellsoft is configured (doesn't matter whether the bellsoft JDK is installed) then openjfx is not installed. When I run apt depend <my-program-name>, I get this output:

$ apt depends scripture-app-builder
scripture-app-builder
  Depends: openjdk-17-jre
  Depends: xdg-utils
  Depends: openjfx
    bellsoft-java11-full
    bellsoft-java11-runtime-full
    bellsoft-java14-full
    bellsoft-java14-runtime-full
    bellsoft-java15-full
    bellsoft-java15-runtime-full
    bellsoft-java16-full
    bellsoft-java16-runtime-full
    bellsoft-java17-full
    bellsoft-java17-runtime-full
    bellsoft-java18-full
    bellsoft-java18-runtime-full
    bellsoft-java19-full
    bellsoft-java19-runtime-full
    bellsoft-java20-full
    bellsoft-java20-runtime-full
    bellsoft-java8-full
    bellsoft-java8-runtime-full
  Depends: libopenjfx-jni

Is there a way from my debian/control file to require openjfx instead of the bellsoft distribution (which none of them get installed)?

Score:0
br flag

I know this is not be exactly what you're asking for, but here is a different approach to solve your problem:

Instead of depending on a specific JDK, you can use jlink (and optionally jpackage) to build a stripped-down Java runtime that you bundle into your package. Since JDK 9 this is treated as the preferred way to package applications for distribution.

Instead of a Depends you would only have a Build-Depends. So if you're primarily shipping binaries (not source packages), this has the following advantages:

  • You would avoid depending on a system-wide JRE installation,
  • which mitigates such dependency problems,
  • reduces the attack surface
  • and gives you full control over the exact runtime configuration.

I have done this myself for a JavaFX application, this rules file might help you get an idea of how to tackle this.

chrish avatar
cn flag
As I mentioned. this JavaFX application is cross-platform with Windows and macOS. On those platforms, I am already building a runtime that gets bundled into the application since there is not an "always there" packaging system like APT on Ubuntu. Thank you for the idea! If we changed to include Java + JavaFX then I might switch to Flatpak instead and widen the distributions that we can run on. Just including Java + JavaFX would be simplier. Thanks for the example `debian/rules` file.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.