When installing Openfire 4.7.0 on a backend Red Hat Linux server, is there any functionality that depends on the graphical elements? I have a RHEL7 server that currently only has java-1.8.0-openjdk-headless which does not provide the ‘java >= 1:1.8.0’ that the Openfire RPM requires. However, it does provide a Java 8 JRE. To get the RPM happy, I’d have to install java-1.8.0-openjdk, which would pull in several more dependencies on things like GTK and other graphical elements that are generally not useful on a headless server.
I’m trying to decide if just installing the Openfire RPM with --nodeps so it does not check/install the dependencies and letting it rely on the headless JRE will work, or if there’s something it’ll be missing/unable to do.
Agreed, this is just trickiness with how the vanilla RPM specifies the java requirement. Suggestions are welcome to how better handle this requirement.
Ok, thanks for the update. I’m by no means an expert in this sort of packaging, but I ended up going down a rabbit hole a bit trying to get a good suggestion. The long and short of it is, I don’t think the method you have now works like you might expect, since the newer-than-java-8 packages no longer provide “java” but rather provide “java-11” or “java-17” and so on. So if I’m understanding correctly, if you have java 11 only installed on your system, it would actually require the installation of java 8 anyway. There doesn’t seem to be a good answer to this until rpm 4.13 which introduces boolean dependencies so you can do something like “Requires (java-headless >= 1:1.8.0 OR java-11-headless)” and rpm 4.13 isn’t available on RHEL7 and prior.
So, short-term, you could change from ‘java >= 1:1.8.0’ to ‘java-headless >= 1.8.0’ (not sure if that last one is 1.8.0 or 1:1.8.0, I’m away from my RHEL box), and it would at least remove the dependency on the graphical toolkits, but it would still have the issue of requiring specifically java 8, and not just >= 8.
Finally, I’ll note I’m only looking at RHEL-provided OpenJDK builds, so not sure how this would affect other JREs.
I think given your statements, and my inability to give any real helpful pointers, I’ll go ahead and install with --nodeps to ignore the dependency to solve this for me in the short term. Appreciate the quick response.
Thanks for the awesome detective work here and yeah, your findings match my recollections when I looked into this a number of moons ago. I think switching to java-headless makes sense and is likely no more broken then the current requirement. Some notes in our issue tracker OF-1443 though are concerning if there is a java-headless package for Oracle