Hi, On Thu, Jul 3, 2025 at 4:59 PM Dimitris Soumis <dsou...@redhat.com> wrote: > > Hi all, > > While working on improving compatibility of the tomcat package with > third-party Java runtimes [1] (i.e. Eclipse Adoptium [2]), I ran into a > persistent and somewhat opaque behavior in Fedora’s Java stack that leads DNF > to always install java-21-openjdk-headless, even when a valid third-party JRE > is already installed and provides the expected.
I understand and fully support the desire to run Tomcat with arbitrary Java at user discretion. > > When installing tomcat, I observed that dnf pulls in java-21-openjdk-headless > even though the relevant spec file has been modified with the relaxed > dependency of Requires: (jre-headless or jre). > I already have temurin-21-jre installed, which provides: jre-headless and jre. > Running dnf install jre-headless correctly resolves to nothing (already > satisfied). > > After investigation, I found out that java-21-openjdk-headless is required by > ecj, which is required by tomcat. I inspected the spec file of ecj and > initially, I suspected the %jpackage_script macro was injecting the > dependency. But even after commenting out that macro in ecj.spec and building > locally, the behavior persisted. > Although I didn't dig deeper, I suspect some maven macros are injecting that > dependency. > > The above result in two noteworthy matters: > 1) Even if a package like tomcat is fully compatible with third-party Java > runtimes, its dependencies (like ecj) defeat that compatibility silently. > 2) Users trying to use supported alternatives like Temurin will always get > Fedora’s OpenJDK installed unless they use non-obvious flags like: dnf > install tomcat --exclude='java*-openjdk*' ecj can be used both as a library (as used by Tomcat) and as a command-line application -- it provides a launcher shell script that needs to invoke a Java JRE. The fact that one package serves two different purposes is the source of the problem you are seeing. In Fedora, Java *libraries* no longer have Requires on any Java, so that they can be easier used with any Java of user choice. Fedora-packaged Java *applications* can follow one of the "Runtime Strategies for Java Applications", typically in one of these categories: 1. Generic Java dependency The package declares a generic java dependency, allowing compatibility with any implementation, including third-party JDKs. The actual runtime is chosen based on available repositories and system alternatives. Examples: Tomcat, LibreOffice 2. Specific OpenJDK version dependency The application explicitly depends on a specific OpenJDK version. Third-party JDKs or alternatives won't affect it. Examples: JFlex, CUP, *ECJ* 3. Version-specific subpackages The package provides bindings for multiple Java versions, and users select the one they need. Examples: Maven, Ant There is not a single best strategy that fits all use cases. Each of them has pros and cons, and package maintainers have the authority to choose what is best for their application. Currently, ecj falls into the second category. However, maintainers can opt to move it into the first category. This would allow the ecj launcher script to invoke whatever Java runtime is present on the system, including third-party distributions like Temurin. Alternatively, and this is my preferred solution, we could split the library part into a separate subpackage, e.g. ecj-lib. In that model: - The main ecj package would remain the command-line tool, with its specific OpenJDK dependency. - The ecj-lib subpackage (used by Tomcat) would not depend on any JRE, preserving full compatibility with any runtime. Either way, I'm happy to help with updating ecj to support running Tomcat with arbitrary Java. > > and two questions: > 1) Should macros automatically inject dependencies, or should this be made > overridable? > 2) Would it be more appropriate for packages like ecj to declare a more > neutral dependency, such as: Requires: (java-headless or jre-headless) ? The %jpackage_script macro can either - generate a script that launches a specific Java, and then generate a dependency on that Java, or - generate a generic script that invokes whatever Java is in PATH, without generating any dependency - it is up to package maintainers to declare appropriate Requires/Recommends in the spec file, or not declare any dependencies at all. Which strategy is used is up to package maintainers -- maintainers know their users and applications and can make the right choice. -- Mikolaj Izdebski > > And other than that, there still exists the need for versioned Temurin rpms > as discussed here. > > I’d be happy to open a bug, but I wanted to raise this for discussion first > to see if others have encountered the same challenge or have best practices > to suggest. > > Thanks for your time and input. > > > P.S. Such cases were what I was worrying about and I mentioned at the > discussion of the proposal :) > > Kind regards, > Dimitris Soumis > > [1] Relevant BZ#2374859 > [2] change proposal > -- > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
