jre-openjdk-headless and jre-openjdk are in conflict

kde-user

Hello,

I’ve just tried to update my system:

❯ sudo pacman -Syu
[sudo] password for xxx:
:: Package databases are synchronized...
  cachyos-v3 106.3 KiB 111 KiB/s 00:01 [------------------------------------------------ -] 100%
  cachyos-core-v3 124.5 KiB 458 KiB/s 00:00 [--------------------------------- ---] 100%
  cachyos-extra-v3 3.6 MiB 6.98 MiB/s 00:01 [-------------------------------- -----] 100%
  cachyos 395.8 KiB 1151 KiB/s 00:00 [------------------------------------------------] 100%
  core 132.5 KiB 712 KiB/s 00:00 [------------------------------------------------] 100%
  extra 8.2 MiB 6.58 MiB/s 00:01 [------------------------------------------------ -] 100%
  multilib 141.1 KiB 811 KiB/s 00:00 [------------------------------------------------] 100%
::Starting full system update...
Update notice:
:: Do you want to continue? [Y/n] y
Warning: appstream-glib: Local version (0.8.2-3.1) is newer than extra (0.8.2-3)
Warning: avidemux-cli: Local version (2.8.1-2.1) is newer than extra (2.8.1-2)
Warning: avidemux-qt: Local version (2.8.1-2.1) is newer than extra (2.8.1-2)
Warning: bubblewrap: Local version (0.8.0-1.1) is newer than extra (0.8.0-1)
Warning: compiler-rt: Local version (16.0.6-2.1) is newer than extra (16.0.6-2)
Warning: cpupower: Local version (6.5-1.1) is newer than cachyos (6.3-5)
Warning: db: Local version (6.2.32-2.1) is newer than cachyos-core-v3 (6.2.32-1.1)
Warning: exiv2: Local version (0.28.0-3.1) is newer than extra (0.28.0-3)
Warning: ffmpeg4.4: Local version (4.4.4-4) is newer than cachyos-extra-v3 (4.4.4-3.1)
Warning: gd: Local version (2.3.3-7.1) is newer than extra (2.3.3-7)
Warning: gobject-introspection-runtime: Local version (1.78.1-1.1) is newer than extra (1.78.1-1)
Warning: gsl: Local version (2.7.1-3.1) is newer than extra (2.7.1-3)
Warning: gst-libav: Local version (1.22.6-1.1) is newer than extra (1.22.6-1)
Warning: gst-plugins-bad: Local version (1.22.6-1.1) is newer than extra (1.22.6-1)
Warning: gst-plugins-bad-libs: Local version (1.22.6-1.1) is newer than extra (1.22.6-1)
Warning: gst-plugins-base: Local version (1.22.6-1.1) is newer than extra (1.22.6-1)
Warning: gst-plugins-base-libs: Local version (1.22.6-1.1) is newer than extra (1.22.6-1)
Warning: gst-plugins-ugly: Local version (1.22.6-1.1) is newer than extra (1.22.6-1)
Warning: gstreamer: Local version (1.22.6-1.1) is newer than extra (1.22.6-1)
Warning: handbrake: Local version (1.6.1-2.1) is newer than extra (1.6.1-2)
Warning: icu: Local version (73.2-2.1) is newer than core (73.2-2)
Warning: iproute2: Local version (6.5.0-2) is newer than cachyos-core-v3 (6.5.0-1.1)
:: replace kuserfeedback with extra/kuserfeedback5? [Y/n] j
Warning: ldns: Local version (1.8.3-2.1) is newer than core (1.8.3-2)
Warning: libelf: Local version (0.189-3.1) is newer than core (0.189-3)
Warning: libgirepository: Local version (1.78.1-1.1) is newer than extra (1.78.1-1)
Warning: libgit2: Local version (1:1.7.1-1.1) is newer than extra (1:1.7.1-1)
Warning: libimobiledevice: Local version (1.3.0-9.1) is newer than extra (1.3.0-9)
Warning: libmpcdec: Local version (1:0.1+r475-4.1) is newer than extra (1:0.1+r475-4)
Warning: libnice: Local version (0.1.21-2.1) is newer than extra (0.1.21-2)
:: Replace libqaccessibilityclient with extra/libqaccessibilityclient-qt5? [Y/n] j
Warning: libqrtr-glib: Local version (1.2.2-2.1) is newer than extra (1.2.2-2)
Warning: libtiff: Local version (4.6.0-2) is newer than cachyos-extra-v3 (4.6.0-1.1)
Warning: liburing: Local version (2.4-1.1) is newer than extra (2.4-1)
Warning: libusb-compat: Local version (0.1.8-1.1) is newer than extra (0.1.8-1)
Warning: libvorbis: Local version (1.3.7-3.1) is newer than extra (1.3.7-3)
Warning: llvm: Local version (16.0.6-1.1) is newer than extra (16.0.6-1)
Warning: llvm-libs: Local version (16.0.6-1.1) is newer than extra (16.0.6-1)
Warning: lv2: Local version (1.18.10-1.1) is newer than extra (1.18.10-1)
Warning: pahole: Local version (1:1.25-5) is newer than cachyos-extra-v3 (1:1.25-4.1)
Warning: perl-clone: Local version (0.46-3) is newer than cachyos-extra-v3 (0.46-2.1)
Warning: phonon-qt5-gstreamer: Local version (4.10.0-4.1) is newer than extra (4.10.0-4)
Warning: polkit-qt5: Local version (0.114.0-2.1) is newer than extra (0.114.0-2)
Warning: python-gobject: Local version (3.46.0-1.1) is newer than extra (3.46.0-1)
Warning: python-pycups: Local version (2.0.1-6.1) is newer than extra (2.0.1-6)
Warning: python-pyqt5: Local version (5.15.10-1.1) is newer than extra (5.15.10-1)
Warning: qca-qt5: Local version (2.3.7-2.1) is newer than extra (2.3.7-2)
Warning: qt6-multimedia-ffmpeg: Local version (6.6.0-1.1) is newer than extra (6.6.0-1)
Warning: raptor: Local version (2.0.16-3.1) is newer than extra (2.0.16-3)
Warning: rav1e: Local version (0.6.6-4) is newer than cachyos-extra-v3 (0.6.6-3.1)
Warning: rtkit: Local version (0.13-2.1) is newer than extra (0.13-2)
Warning: spirv-tools: Local version (2022.4-1.1) is newer than extra (2022.4-1)
Warning: sratom: Local version (0.6.14-1.1) is newer than extra (0.6.14-1)
Warning: wxwidgets-common: Local version (3.2.3-1.1) is newer than extra (3.2.3-1)
Warning: wxwidgets-gtk3: Local version (3.2.3-1.1) is newer than extra (3.2.3-1)
Warning: zsh: Local version (5.9-4.1) is newer than extra (5.9-4)
Dependencies are resolved...
looking for conflicting packages...
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: jre-openjdk-headless and jre-openjdk are in conflict

I googled this before and came across this thread from yesterday:
https://bbs.archlinux.org/viewtopic.php?id=290066

But I don’t really dare to try out any of the suggested solutions there!
Among other things, because I may have different dependency relationships than the users there and because the packages were installed for me by cachyos-extra-v3.

A pacman -Qi for the two packages gives me the following:

❯ pacman -Qi jre-openjdk
Installed by: cachyos-extra-v3
Name: jre-openjdk
Version: 21.u35-3.1
Description : OpenJDK Java 21 full runtime environment
Architecture: x86_64
URL: https://openjdk.java.net/
Licenses: custom
Groups: Nothing
Provides : java-runtime=21 java-runtime-openjdk=21 jre21-openjdk=21.u35-3.1
Depends on: jre21-openjdk-headless=21.u35-3.1 giflib libgif.so glibc gcc-libs libpng
Optional dependencies: alsa-lib: for basic sound support [Installed]
                            gtk2: for the Gtk+ 2 look and feel - desktop usage [Installed]
                            gtk3: for the Gtk+ 3 look and feel - desktop usage [Installed]
Required by: jdownloader2 mediathekview
Optional for: libbluray libjpeg-turbo libjxl
Conflicts with: Nothing
Replaced: Nothing
Installation size: 585.86 KiB
Packer: CachyOS <admin@cachyos.org>
Created on : Sun Sep 24, 2023 1:52:11 PM CEST
Installed on : Tue Sep 26, 2023 3:19:27 PM CEST
Installation Reason: Installed as a dependency of another package
Installation script: Yes
Verified by : Signature


~
❯ pacman -Qi jre-openjdk-headless
Installed by: cachyos-extra-v3
Name: jre-openjdk-headless
Version: 21.u35-3.1
Description : OpenJDK Java 21 headless runtime environment
Architecture: x86_64
URL: https://openjdk.java.net/
Licenses: custom
Groups: Nothing
Provides : java-runtime-headless=21 java-runtime-headless-openjdk=21
                            jre21-openjdk-headless=21.u35-3.1
Depends on : java-runtime-common>=3 ca-certificates-utils nss libjpeg-turbo libjpeg.so=8-64
                            lcms2 liblcms2.so=2-64 libnet freetype2 libfreetype.so=6-64 harfbuzz
                            libharfbuzz.so=0-64 glibc gcc libs
Optional dependencies: java-rhino: for some JavaScript support
Required by: jre-openjdk
Optional for: Nothing
Conflicts with: Nothing
Replaced: Nothing
Install size: 192.74 MiB
Packer: CachyOS <admin@cachyos.org>
Created on : Sun Sep 24, 2023 1:52:11 PM CEST
Installed on : Tue Sep 26, 2023 3:19:27 PM CEST
Installation Reason: Installed as a dependency of another package
Installation script: Yes
Verified by : Signature

(The command outputs have been run through Google Translate! So not all expressions may be exactly as they would be in the original English terminal output.)

As you can see, both packages have some dependencies.

I’m also wondering, like the questioner in the other thread mentioned above, where does this conflict suddenly come from, since the packages were already installed next to each other (and both are probably needed)?

And does anyone have an idea how I could solve this?

MBK

kde-user
I had this issue when arch made the change a couple weeks ago.
It’s badly designed/incompetent crap like this by the arch developers that makes archlinux unusable for normal users. (-> a competent well designed packaging system should take care of this by itself).

Just uninstall both jre packages together (“sudo pacman -R jre-openjdk-headless jre-openjdk”) (this will also uninstall packages that depend on them), and reinstall the one you want (jre-openjdk on desktop, jre-openjdk-headless on headless server).

But from the arch post, you can also try to install the jdk (they say it will remove the jre), and then if it worked try to replace the jdk with the jre (or just keep the jdk): “If you have both JDK and JRE installed you can manually install the JDK with pacman -Syu jdk-openjdk and this removes the JRE related packages.”

kde-user

I’ve been experimenting in the VM (where is the same situation) a bit now…

In the above link to the Archlinux thread, post number 6 seems to me to be the most comprehensive suggested solution. I’ll just quote this here:

Just do

# pacman -S jre-openjdk

You’ll see

Sync Dependency (1): jre-openjdk-21.u35-7                                                                                                                                                                                                      
resolving dependencies...                                                                                                                                                                                                                      
looking for conflicting packages...                                                                                                                                                                                                            
:: jre-openjdk and jre-openjdk-headless are in conflict. Remove jre-openjdk-headless? [y/N]

and you can answer ‘y’ to remove jre-openjdk-headless. Then, if jre-openjdk was originally installed as a dependency for some other package, you can mark it as such by

# pacman -D --asdeps jre-openjdk

In the console it looks like this:

❯ sudo pacman -S jre-openjdk
[sudo] password for xxx: 
resolving dependencies...
looking for conflicting packages...
:: jre-openjdk and jre-openjdk-headless are in conflict. Remove jre-openjdk-headless? [y/N] y

Package (2)           Old Version  New Version  Net Change 

jre-openjdk-headless  21.u35-3                  -192.59 MiB
extra/jre-openjdk     21.u35-3     21.u35-7      152.35 MiB

Total Installed Size:  152.93 MiB
Net Upgrade Size:      -40.24 MiB

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                                               [--------------------------------------------] 100%
(1/1) checking package integrity                                             [--------------------------------------------] 100%
(1/1) loading package files                                                  [--------------------------------------------] 100%
(1/1) checking for file conflicts                                            [--------------------------------------------] 100%
:: Processing package changes...
No Java environment is set as default anymore
(1/1) removing jre-openjdk-headless                                          [--------------------------------------------] 100%
(1/1) upgrading jre-openjdk                                                  [--------------------------------------------] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Checking which packages need to be rebuilt
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_GB",
        LC_ALL = (unset),
        LC_ADDRESS = "de_DE.UTF-8",
        LC_NAME = "de_DE.UTF-8",
        LC_MONETARY = "de_DE.UTF-8",
        LC_PAPER = "de_DE.UTF-8",
        LC_IDENTIFICATION = "de_DE.UTF-8",
        LC_TELEPHONE = "de_DE.UTF-8",
        LC_MEASUREMENT = "de_DE.UTF-8",
        LC_TIME = "de_DE.UTF-8",
        LC_NUMERIC = "de_DE.UTF-8",
        LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_GB",
        LC_ALL = (unset),
        LC_ADDRESS = "de_DE.UTF-8",
        LC_NAME = "de_DE.UTF-8",
        LC_MONETARY = "de_DE.UTF-8",
        LC_PAPER = "de_DE.UTF-8",
        LC_IDENTIFICATION = "de_DE.UTF-8",
        LC_TELEPHONE = "de_DE.UTF-8",
        LC_MEASUREMENT = "de_DE.UTF-8",
        LC_TIME = "de_DE.UTF-8",
        LC_NUMERIC = "de_DE.UTF-8",
        LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_GB",
        LC_ALL = (unset),
        LC_ADDRESS = "de_DE.UTF-8",
        LC_NAME = "de_DE.UTF-8",
        LC_MONETARY = "de_DE.UTF-8",
        LC_PAPER = "de_DE.UTF-8",
        LC_IDENTIFICATION = "de_DE.UTF-8",
        LC_TELEPHONE = "de_DE.UTF-8",
        LC_MEASUREMENT = "de_DE.UTF-8",
        LC_TIME = "de_DE.UTF-8",
        LC_NUMERIC = "de_DE.UTF-8",
        LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

~ 59s
❯ sudo pacman -D --asdeps jre-openjdk
jre-openjdk: install reason has been set to 'installed as dependency'

I don’t know what these perl warnings are all about! Is this a problem?

Then I restarted the system and started JDownloader as a test (MediathekView doesn’t start in my VM anyway because I apparently don’t have enough RAM there!).
JDownloader starts normally!
So apparently problem solved?!

kde-user

In the meantime, the Archlinux thread mentioned in post 1 continued and there is now reference to an Archlinux news as a solution:
https://archlinux.org/news/incoming-changes-in-jdk-jre-21-packages-may-require-manual-intervention/

To be honest, even though I translated this news into German via Translater, I don’t really understand it!

There is written once by jre and once by jdk. And if you have one or the other or both, you should do this or that.

But in my case I have both terms in both package names (jre-openjdk and jre-openjdk-headless). So both packages somehow contain both jdk and jre?!

So I don’t know which part of the news I should use as a solution for myself!

kde-user

MBK

For me the questions start with what I actually have installed, jre or jdk or both. Unfortunately, I completely lack understanding.

From the news you linked (I had already linked it in my previous post), two approaches may come into consideration for me. I played through both in the VM (and then reset them again using Timeshift):

“If you have both JDK and JRE installed …”
-> How do I know what is installed on me? I had jre-openjdk and jre-openjdk-headless installed. Both names contain both jre and jdk, so what is it, both?
In the case it goes on to say: “… you can manually install the JDK with pacman -Syu jdk-openjdk and this removes the JRE related packages.”
That would work, jre-openjdk would be uninstalled, jdk-openjdk would be installed.
It is then installed as follows:

pacman -Qs | grep -E "jre|jdk"
local/jdk-openjdk 21.u35-7

jre-openjdk-headless was also thrown out.
The JDownloader as a test program, which requires Java, would then start.

“If you have both JRE and JRE-headless …”
-> Could also fit my situation, jre-openjdk and jre-openjdk-headless are installed.
“… you will need to choose one of them and install it manually since they would conflict with each other now.”
I choosed jre-openjdk. This is what I wrote in post 2 in the terminal output. So that works too!

However, the console output says, among other things:
No Java environment is set as default anymore
This doesn’t seem to bother the JDownloader, which starts anyway. Is this still a problem for other programs?

And it’s still unclear to me: In the second case, should I then execute the following command (which I got from the forum post mentioned above):
sudo pacman -D --asdeps jre-openjdk
This would result in: “install reason has been set to ‘installed as dependency’”
And, should I perhaps do that too if I took option 1?

So, which is correct or more correct, option 1 or 2?

MBK

kde-user
As you said you have jre installed (not jdk). : ‘jre-openjdk-headless and jre-openjdk are in conflict’

jre is the java runtime environment.
jdk in the full java development kit (it also contains the jre)

If you don’t plan to develop on java, but only what to run java apps -> you want the jre (but the jdk will work as well, but it will just install the full kit which you don’t need).

-> just do what I said in my previous post.

And if you want to easily/visually see what you have installed -> just search for it in octopi.

kde-user

Sorry, double-post!

kde-user

MBK

Now I did it like I wrote in post 2:

So first:
sudo pacman -S jre-openjdk

As expected, this uninstalled jre-openjdk-headless, because of the (new) existing conflict.

After that I still have:
sudo pacman -D --asdeps jre-openjdk

That seemed plausible to me because the jre-openjdk was actually installed as a dependency somewhere at some point.

Then I did a system update with sudo pacman -Syu.

Unfortunately, the Mediathekview program no longer works. 🙁
It still starts, but the window then remains empty, only a bar can be seen at the top and I can no longer click on anything. Only the close (X) button still works.

I’ve also uninstalled it using sudo pacman -Rs mediathekview and then installed it again - without any changes.

Well, what could be the reason?

But I didn’t pay attention to whether Mediathekview was updated during the system update.

Maybe that has nothing to do with the Java back and forth!

PS: I have an other program JDownloader, that also needs java, and that program still works. So it shouldn’t actually be due to Java.

kde-user

It may have something to do with Java that MediathekView no longer works.

I started it via the console and there is the following output in endless output:

Exception in thread "JavaFX Application Thread" java.lang.NoClassDefFoundError: jdk/swing/interop/SwingInterOpUtils
        at com.sun.javafx.embed.swing.newimpl.JFXPanelInteropN.postEvent(JFXPanelInteropN.java:36)
        at javafx.embed.swing.JFXPanel.invokeOnClientEDT(JFXPanel.java:938)
        at javafx.embed.swing.JFXPanel$HostContainer.setCursor(JFXPanel.java:1034)
        at com.sun.javafx.tk.quantum.EmbeddedScene.setCursor(EmbeddedScene.java:439)
        at javafx.scene.Scene$MouseHandler.updateCursorFrame(Scene.java:4015)
        at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2551)
        at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:405)
        at java.base/java.security.AccessController.doPrivileged(Unknown Source)
        at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:404)
        at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:434)
        at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:575)
        at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:555)
        at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:548)
        at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352)
        at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
        at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
        at com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(GtkApplication.java:316)
        at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: jdk.swing.interop.SwingInterOpUtils
        ... 18 more
Exception in thread "JavaFX ...

Can anyone explain what that means?

MBK

kde-user

Perhaps it doesn’t like the latest java version.

Have you tried with other java versions? jre17 ?

kde-user

I’ve just installed sudo pacman -S jdk-openjdk.
The conflict with jre-openjdk was then highlighted (as expected) and I agreed to uninstall the latter.

And suddenly MediathekView is running again!!

jdk-openjdk is installed at version 21.u35-7.

So with this “we will be making them conflict” and “This will … require a manual user action” the guys at Archlinux have really come up with something nice! 😉

Because I had already suspected that there could be difficulties, and didn’t know, what to do right, I was extra careful, informed myself and then wanted to do everything right - but it wasn’t possible!

kde-user

@MBK
PS:
Your suggestion with jre17-openjdk would have worked too.
I just tried this in the VM …

I first wanted to uninstall jre-openjdk (21.u35-7), but that wasn’t possible because it would have broken dependencies (MediathekView, JDowloader).

Then I also installed jre17-openjdk and then jre-openjdk could be uninstalled.

MediathekView runs with jre17!

jre17-openjdk would have been the “slimmer” solution (jdk-openjdk 1136.48 MiB vs. jre17-openjdk 171.75 MiB).
I don’t know to what extent it would have been “outdated” and would have had to be replaced sooner or later anyway.

I think I’ll leave jdk-openjdk installed on my main system now, even though it actually takes up a lot of disk space, and hope there aren’t any more surprises with it!

MBK

kde-user

FYI, I just installed mediathekview from the arch/extra repo. It works fine with jre 21 (no jdk installed).

kde-user

MBK
Have you tried starting the filter (the little filter icon)?

I just looked in one of my VMs, where I also installed MediathekView + jre-openjdk (21). MediathekView now starts again there and loads the film list.
But if you then want to use for example the filter, an empty window opens for me. I was then able to close this window again, but the program was unusable (despite the program list being loaded), it didn’t respond to anything, only the close button still worked!

As far as I have seen, at least one Java update has been released in the meantime, which is probably responsible for the fact that MediathekView now seems to start properly.

But I also happened to stumble across a thread today, where some people have the same problem as me:
https://forum.archlinux.de/d/35024-mediathekview-mit-aktuellem-java

I don’t know what languages you speak, but the thread is in German.
Otherwise you might have to translate somehow; The (albeit poor) translation function has recently been introduced in Firefox. Or else just Google Translate, which can be used to translate entire pages.

So I’m not the only one with these problems. Others also write there, that it works with java-17-openjdk or with jdk-openjdk.
The first posts reported, that jre-openjdk completely freezes (like it did for me back then) and produces endless error messages in the terminal, like it did for me.
Later it is reported (apparently after the interim Java update) that it seems to work at first, but then not, when you click on filters for example - just like it did for me.

MBK

kde-user Have you tried starting the filter (the little filter icon)?

Ah, you are right. It freezes.

It looks like this is a problem with this app with this java version.

Nothing cachyos can do. -> just use jre17 until this gets fixed.

ptr1337

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

See here

kde-user

MBK Nothing cachyos can do

Yes, it has long been clear in this thread, that this is a general Archlinux/Java problem.

Just as I posted the same link 11 days ago, as ptr1337 has now posted again, with the explanation/news from Archlinux.

But the jre-openjdk (updated 21er version) would probably have caused problems in connection with MediathekView anyway, regardless of this Archlinux problem that the different Java versions were intentionally brought into conflict with each other.