Jre17-openjdk vs jdk17-openjdk (conflicting)

Hello, I may be overlooking something:
System upgrader is presenting me with a package conflict:

:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
warning: removing 'jre17-openjdk-17.0.10.u7-3' from target list because it conflicts with 'jdk17-openjdk-17.0.10.u7-3'
warning: removing 'jre17-openjdk-headless-17.0.10.u7-3' from target list because it conflicts with 'jdk17-openjdk-17.0.10.u7-3'
:: jdk17-openjdk-17.0.10.u7-3 and jre17-openjdk-17.0.10.u7-1 are in conflict. Remove jre17-openjdk? [y/N] 

I can’t see what’s the conflict, since Java runtime and JDK seem to have updated fine so far:

[2024-01-19T19:09:32+0100] [ALPM] upgraded jre17-openjdk-headless (17.0.9.u8-2 -> 17.0.10.u7-1)
[2024-01-19T19:09:32+0100] [ALPM] upgraded jre17-openjdk (17.0.9.u8-2 -> 17.0.10.u7-1)
[2024-01-19T19:09:33+0100] [ALPM] upgraded jdk17-openjdk (17.0.9.u8-2 -> 17.0.10.u7-1)

Any idea?
Thanks, Michael.

Should be the same principle for Jre17 - jdk17, read here.

https://archlinux.org/news/incoming-changes-in-jdk-jre-21-packages-may-require-manual-intervention/

It seems like the Arch maintainers have decided to backport the packaging method for JDK 21 to older versions.

Basically, jdk17-openjdk already provides the Java 17 runtime, so if you already have jdk17-openjdk installed, you don’t have to have jre17-openjdk installed as well.

This wasn’t the case previously. The maintainers have recently decided to change the way the openjdk toolchains are packaged in Arch. That’s all there is to it.

This is quite simple to deal with:

  1. If you are writing code in java, remove jre17-openjdk.
  2. If you are not writing code in java and you’re only interested in running applications that are written in Java, remove jdk17-openjdk.

Since you already have jdk17-openjdk installed, I’m assuming that you’ve been writing Java code. Therefore, choose option 1.

Hi Anthony, sorry I’m late with my reply to @sammiev. So your and my response crossed in parts:

Actually, no.
Just before I asked that myself and therefore browsed pacman.log.
I’ve yet not seen any reason why I got the JDK installed. :thinking:
But I’m using Logisim which needs a JRE v16 or newer.
So I just removed the JDK.
The Arch article, sammiev referred to, also says I’ve to decide whether I go with jre…-openjdk-headless or jre…-openjdk.
Since Logisim needs a GUI, I’d go with jre17-openjdk.
So I manually tried to remove jre17-openjdk-headless.
Since this is before v21 I get a dependency conflict:

$ sudo pacman -R jre17-openjdk-headless
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing jre17-openjdk-headless breaks dependency 'jre17-openjdk-headless=17.0.10.u7-1' required by jre17-openjdk

but a system upgrade suggests to delete jre17-openjdk-headless:

resolving dependencies...
looking for conflicting packages...
warning: removing 'jre17-openjdk-headless-17.0.10.u7-3' from target list because it conflicts with 'jre17-openjdk-17.0.10.u7-3'
:: jre17-openjdk-17.0.10.u7-3 and jre17-openjdk-headless-17.0.10.u7-1 are in conflict. Remove jre17-openjdk-headless? [y/N] 

Which, to my logic, would also fail.
Of course I could remove jre17 all-together, but then pacman wouldn’t let me remove the JRE because of Logisim depending on it.

… which, actually, didn’t.
The upgrade worked now, by letting it remove the headless package.

I couldn’t find any “force” (or similar) option for ‘pacman -R’.
How would I replace the JRE v17 packages with newer ones?
I can’t just remove it because of dependencies to Logisim.

Just rebuild logisim first.

This is the latest dependency list for logisim as listed in its AUR page.

As you can see, the latest version of logisim requires java-runtime, which can be provided by either jdk17-openjdk or jre17-openjdk (any one of those packages listed inside the parenthesis will provide the java-runtime)

Rebuild logisim, and then remove jre17-openjdk when prompted to do so in your next update.

Ok, but installation requires me to decide between JDKs and not JREs:

$ yay -S logisim-evolution
:: There are 3 providers available for java-environment>=16:
:: Repository extra
    1) jdk-openjdk 2) jdk17-openjdk 3) jdk21-openjdk 

Enter a number (default=1): 
==> 

Like I mentioned already, everything inside the jre packages are now included inside the jdk packages. Just pick jdk17-openjdk in this case, since you’ve been using Java 17.

Installing jdk17-openjdk would give you the most flexibility since it also provides tools for you to compile java code.

Then I don’t see why I would need to do anything now, since I got the original conflict resolved.
My idea is to upgrade to a JRE (I don’t need a JDK) v21 or newer, to set up my system to Arch’s new way to package JRE and JDK and therefore avoiding potential future conflicts.

Yes, that’s what I understood from reading the originally mentioned Arch posting.
I naïvely assumed that installing the JRE first would be sufficient since I don’t need the JDK.
But, for whatever reason, logisim-evolution-bin requires a JDK for installation. *)
Although, AFAICT, the AUR doesn’t require this specifically:
https://aur.archlinux.org/cgit/aur.git/commit/?h=logisim-evolution-bin&id=5387fee207ea209690205d682b6c7b5e5e6391a0

I don’t seem to understand Arch’s dependency mechanism entirely:
Yes, now the JDK/JRE packages are kind of nested, but still - also with v22 - all sub packages (JRE, JRE-headless) are still available.
Is this still the AUR specifically requiring the JDK and not the JRE, and I was looking at the wrong place, or is this elsewhere in the system formulating this dependency?

*) pacman.log seems to confirm that the JDK came with the original installation of the AUR.
And back then the JRE was a dependency of the JDK, if I got this right.

No. logisim-evolution-bin only needs java-environment (provided by jdk-openjdk) during the build process. It doesn’t require java-environment to run.

Go to logisim-evolution-bin’s AUR page and read the list of dependencies. You’ll see that there is a (make) label beside the java-environment dependency. This means that java-environment is a make dependencency (only required during installation).

That is why I mentioned earlier to choose the jdk-openjdk variants for maximum flexibility.

With jre17-openjdk, you can only run java 17 code.
With jdk17-openjdk, you can run and compile java 17 code.

For your use case, I’d just remove jre17-openjdk and keep jdk17-openjdk. It’s really not that complicated.

1 Like

Been there, overlooked it!
In fact the maintainer left a comment:

 Paragoumba commented on 2021-12-30 12:59 (UTC) (edited on 2021-12-30 12:59 (UTC) by Paragoumba)

I added java-environment as a makedependency

Got it now, thanks for your patience!

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.