The FreeBSD ports tree contains KDE Frameworks 6 and KDE Plasma 6, e.g. x11/plasma6-plasma-desktop, but KDE applications have not updated in particular, and so FreeBSD does not have the “megarelease” on-tap just now.

As for expectations, I think it’s realistic to say that the first minor release, 6.1, is when FreeBSD ports will switch over to the new stuff. For now, it’s the “previous era” in terms of applications. There are a couple of reasons for that, but they can be distilled down to “lack of developer resources”. There’s a couple of things you can do to help, potentially speeding things up.

Hybrid Systems

It is of course possible to run KDE Frameworks 5 applications (e.g. all the applications in the FreeBSD ports tree) in whatever desktop environment you like. Theoretically that includes KDE Plasma 6, so the combination Plasma 6 from x11/plasma6-plasma and KDE applications like graphics/spectacle is fine. But see the notes on co-installability below.

Running the newer desktop now helps with testing.

There’s a couple of things that needs specific testing off the top of my head:

  • Wayland support from KWin. I could never get KWin from Plasma 5 to work in a Wayland session. Since we (“we” as in FreeBSD KDE ports maintainers) did not have the time to seriously sit down with it, it is probably still broken in some mysterious fashion. Running literally any other Wayland session from the ports tree, with KDE applications, is fine.
  • All the KCMs for system configuration. You’ll probably need to install sysutils/plasma6-kde-cli-tools to get at them. Since system configuration is an integrator’s job, there is likely to be a bunch of breakage there.

Use FreeBSD Bugzilla to report issues, but remember to look for duplicates and most importantly, try to solve the problem and submit a patch. Patches go through the ports tree and then generally go upstream, if they are not outrageously hacky.

13 is Bad Luck

KWin is mostly nice code. Modern, too. It uses C++20 standard library features, in particular std::ranges::subrange. With a suitably new gcc, that’s not a problem. With a suitably new clang, not a problem either.

FreeBSD 13.2 has clang 14.0.5 as system compiler. This is not suitably new. While it supports the C++20 language, the standard library is severely lacking in std::ranges. KWin won’t build.

FreeBSD 13.3 has clang 17.0.5 (release announcement mentions it specifically). One of the big things of clang 17 is its improved standard library. This is suitably new. KWin for KDE Plasma 6 builds fine.

13.2 is still a supported release as far as FreeBSD goes, for one more quarter. It won’t get any KDE Plasma 6 though. Users are encouraged to upgrade to 13.3 – that’s fairly reasonable for desktop use. Or upgrade to 14, to be on the branch that has support until the year 2028.

What About KDE Plasma 5

Plasma 5 is hanging around as long as we don’t have a full working Plasma 6, and as long as there are supported releases of FreeBSD that can’t build Plasma 6. That’s about 3 months, assuming there is no big breakage.

And, of course, the ports tree can be switched to whatever snapshot or branch you like, so you can still build today’s ports six months from now.

Co-installability

For testing it would be great to have KDE Plasma 5 and Plasma 6 installed at the same time, so it is easy to switch between the two. Short answer: it ain’t gonna happen.

This just comes down to available developer time. There are things that can be co-installed: KDE Frameworks 5 and Frameworks 6 (most of them, anyway). But once we reach the whole desktop experience, a lot more of the software stack comes into play.

Here are some examples:

  • Infrastructure that provides binaries:
    • signon-qt6-8.61 conflicts with signon-qt5-8.61 on /usr/local/bin/signond . Since it’s a DBus service it is probably compatible and we could depend on either one, doesn’t matter. But that’s not how dependencies are written in FreeBSD packages, so ..
  • KDE Frameworks that provide binaries and XDG files:
    • kf6-kwallet-6.0.0 conflicts with kf5-kwallet-5.115.0_1 on /usr/local/bin/kwallet-query . I don’t know if the wallet format remains compatible, or if the executables are really all that different. I suppose one or both could be renamed, but that is effort that probably needs to be undone in a couple of months (or a decision could be made to version binaries in general, but that is not going to reduce maintenance burden at all).
    • kf6-baloo-6.0.0 conflicts with kf5-baloo-5.115.0 on /usr/local/etc/xdg/autostart/baloo_file.desktop . Could be versioned, again with the question “to what end” – although I think you would want to start the baloo version corresponding to the KDE Plasma version.
  • Plasma Components that provide binaries or system-wide configuration:
    • plasma6-kactivitymanagerd-6.0.0 conflicts with plasma5-kactivitymanagerd-5.27.10 on /usr/local/lib/libexec/kactivitymanagerd . Same kind of versioning question.
    • plasma6-libplasma-6.0.0 conflicts with kf5-plasma-framework-5.115.0_1 on /usr/local/share/plasma/desktoptheme/breeze-dark/colors . This is probably unimportant, and I would guess that the colors are the same.

All of this is fixable by moving things into a different prefix, or moving things around in packaging, but there is limited mileage in thwacking upstream with a hammer to fit it into packaging system limitations.

Takeaway

On FreeBSD 13.3 and higher, with the default ports tree, KDE Plasma 6 is here, but of limited use as a daily-driver desktop. Expect the rest of the KDE Megarelease to land in the coming three months.

KDE Plasma 6 Desktop on FreeBSD inside VirtualBox (click for full size)
KDE Plasma 6 Desktop on FreeBSD inside VirtualBox (click for full size)

The screenshot here is Plasma 6 in 800x600 mode in VirtualBox – not its natural element, but even there I notice some really nice bits of attention-to-detail. Due to co-installability issues, the best applications (from the ports tree) to run in it are, ironically, anything but KDE applications.