To avoid complications we explicitly avoid installing both JACK (server+libs) and the pipewire jack (libs) installation.

So I think the dependencies are correct. 

The reason for this is that when you install JACK and allow jack clients to both go to JACK or pipewire-jack (using pw-jack) was
confusing. So you either install JACK and apps go to JACK or you install pipewire-jack and apps got to Pipewire.

> Obviously this does not make sense, if anything pipewire-plugin-jack should depend on JACK not it's pipewire reimplementation. 

This obviously does make sense, the pipewire-plugin-jack does not use anything from JACK, so why would it depend on JACK?


> Furthermore, when pipewire-jack-audio-connection-kit and pipewire-jack-audio-connection-kit-libs are installed, they break the existing JACK installation, so it creates a "chicken and egg" problem.

There is no chicken and egg problem, it's either JACK or pipewire-jack, you can't install both, for the above reasons.

I think you assume that the pipewire implementation relies on some JACK server/code but it does not, PipeWire is a complete reimplementation of
a JACK server and client libraries.

(In reply to Wim Taymans from comment #1)

> > Obviously this does not make sense, if anything pipewire-plugin-jack should depend on JACK not it's pipewire reimplementation. 
> 
> This obviously does make sense, the pipewire-plugin-jack does not use
> anything from JACK, so why would it depend on JACK?

You do not understand: pipewire-plugin-jack is a plugin for interfacing pipewire with real JACK. Its whole purpose is to interface with real JACK. 
It serves as a bridge. I can't use real JACK as long as those dependences are installed.
(Annoyingly those dependences are installed as weak dependencies with every pipewire update so it constantly breaks JACK unless blacklisted.)

There is no point in having pipewire-plugin-jack installed with pipewire reimplementation: there is no point in interfacing
pipewire with pipewire using jack protocol.

For those facing the same issue, there is a workaround:
dnf download pipewire-plugin-jack
rpm -i --nodeps pipewire-plugin-jack-1.6.8-1.fc44.x86_64.rpm

Blacklist the dependencies and prevent the next update from wrecking your setup. 

Start Jack with dbus interface and restart pipewire.
New node will appear in pipewire and in Jack.

> There is no point in having pipewire-plugin-jack installed with pipewire reimplementation: there is no point in interfacing
pipewire with pipewire using jack protocol.

Ah I see.

The jack plugin uses dlopen to load the jack implementation of the client API so it only interfaces with JACK and should not care or use
the pipewire jack implementation.

The rpm has these Requires:

Requires:       %{name}-jack-audio-connection-kit-libs = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
Requires:       jack-audio-connection-kit

Which I guess the pipewire-jack-audio-connection-kit-libs now causing problems because it conflicts with JACK. This is because
we moved the pw-jack executable in the libs and no longer allow JACK+pw-jack installed together.

I guess that dependency should be removed now?

> The rpm has these Requires:
> 
> Requires:       %{name}-jack-audio-connection-kit-libs =
> %{version}-%{release}
> Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
> Requires:       jack-audio-connection-kit
> 
> Which I guess the pipewire-jack-audio-connection-kit-libs now causing
> problems because it conflicts with JACK. This is because
> we moved the pw-jack executable in the libs and no longer allow JACK+pw-jack
> installed together.
> 
> I guess that dependency should be removed now?

Yes. 
Also there is nothing that prevents the installation of pipewire-jack-audio-connection-kit alongside jack-audio-connection-kit.
Packages should be updated to prevent that from happening, considering that pipewire-jack-audio-connection-kit is a weak dependency
for pipewire.