m (→Install KDE) |
(→Update Schedule: Revise update schedule to match new policy agreed this week) |
||
| Line 43: | Line 43: | ||
== Update Schedule == | == Update Schedule == | ||
EPEL Users are running on a stable Enterprise Linux, and expect stability. KDE is a fairly fast updating desktop. If it isn't updated fairly regularly, it is hard to keep up with bugs and security issues. After discussion, the KDE | EPEL Users are running on a stable Enterprise Linux, and expect stability. KDE is a fairly fast updating desktop. If it isn't updated fairly regularly, it is hard to keep up with bugs and security issues. After discussion, the KDE SIG decided that twice a year update would give users the stability they want, along with the updates they need. | ||
=== Update Timing === | === Update Timing === | ||
Plasma releases will be synchronized from Fedora to EPEL after each | Plasma releases will be synchronized from Fedora to EPEL after each Fedora release (e.g., F38, F39, and so on) | ||
The | The update will correspond with a RHEL release. It will first go into the epel-next repo, and be built on Stream. When the corresponding RHEL release is released, all the epel-next packages will be rebuilt on regular epel. | ||
=== Security and Bugfixes === | === Security and Bugfixes === | ||
This | This twice a year update schedule will catch most of the major bugs and security issues. But there will be times when this gets difficult, particularly in the middle of the year. The KDE SIG will give a best-effort attempt to backport fixes from future stable releases as needed, but if not possible, rebasing Plasma remains an option. | ||
=== | === Qt updates in RHEL === | ||
RHEL coordination for Qt will be included as part of this effort to align to | RHEL coordination for Qt will be included as part of this effort to align to RHEL releases. | ||
Revision as of 11:19, 28 January 2023
KDE on EPEL
KDE was part of RHEL up until RHEL 8. At that point the majority of KDE was removed, with only some qt5 packages left. This allowed the EPEL community to build KDE Plasma Desktop in EPEL.
Installation
Install epel-release
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
Enable codeready-builder or PowerTools
If RHEL 8:
- subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms
If CentOS 8:
- dnf config-manager --enable powertools
Install KDE
- dnf group install kde-desktop-environment
or
- dnf group install kde-desktop
- (Optional) dnf group install kde-apps
- (Optional) dnf group install kde-media
- (Optional) dnf group install kde-education
- (Optional) dnf install okular
- (Optional) dnf group install kde-software-development
- (Optional) dnf group install kf5-software-development
(Optional if Workstation already installed) Set sddm as desktop manager
- systemctl set-default graphical.target
- dnf install sddm\*
- systemctl enable sddm -f
- reboot
(If Workstation already installed, and didn't enable sddm)
- systemctl reload gdm
(Optional) Install apps via flatpak
- dnf -y install flatpak
- flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
- flatpak install flathub org.kde.kdenlive
- flatpak install flathub org.kde.krita
Update Schedule
EPEL Users are running on a stable Enterprise Linux, and expect stability. KDE is a fairly fast updating desktop. If it isn't updated fairly regularly, it is hard to keep up with bugs and security issues. After discussion, the KDE SIG decided that twice a year update would give users the stability they want, along with the updates they need.
Update Timing
Plasma releases will be synchronized from Fedora to EPEL after each Fedora release (e.g., F38, F39, and so on)
The update will correspond with a RHEL release. It will first go into the epel-next repo, and be built on Stream. When the corresponding RHEL release is released, all the epel-next packages will be rebuilt on regular epel.
Security and Bugfixes
This twice a year update schedule will catch most of the major bugs and security issues. But there will be times when this gets difficult, particularly in the middle of the year. The KDE SIG will give a best-effort attempt to backport fixes from future stable releases as needed, but if not possible, rebasing Plasma remains an option.
Qt updates in RHEL
RHEL coordination for Qt will be included as part of this effort to align to RHEL releases.