On Thu, Jul 3, 2025 at 10:34 PM Mikolaj Izdebski <mizde...@redhat.com> wrote:
> 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 > > Hi Mikolaj, Thank you for the detailed and informative reply. The idea of splitting ecj into ecj and ecj-lib makes a lot of sense to me. It would serve the purpose of keeping Tomcat and similar applications runtime agnostic. I will move forward by opening a bugzilla to track this issue. Kind regards, Dimitris Soumis
-- _______________________________________________ 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
