The Catalyst: Fedora 41 and Wayland
When I upgraded from Fedora 40 to 41, I didn't expect it to lead me down a path of discovery in Linux package development. The upgrade brought several changes, but the most impactful was the complete shift to Wayland from X11. As someone who regularly used screen recording tools, this change immediately affected my workflow - I suddenly couldn't use my trusty Peek screen recorder, which relied on X11.
💡
X11 (also known as X Window System) and
Wayland are display server protocols - they're responsible for handling how applications draw things on your screen and interact with input devices like your mouse and keyboard. X11 has been the standard for decades, but it was designed in the 1980s and carries a lot of legacy baggage. Wayland is its modern replacement, designed to be more secure, efficient, and better suited for today's graphics and display technologies. Think of it like upgrading from an old tube TV to a modern smart TV - same basic function, but with better technology under the hood.
The Search for Alternatives
After some searching, I found Kooha, a modern screen recorder designed with Wayland in mind.
Perfect! But there was a catch: it was only available as a Flatpak. For those unfamiliar, Flatpak is a package format that bundles an application with all its dependencies, making it work across different Linux distributions. While this is excellent for compatibility, it came with significant overhead:
Flatpak Installation:
- GNOME Platform (46): 364.0 MB
- GNOME Platform Locale: 379.2 MB
- GL/Graphics drivers: 350.2 MB
• GL default: 168.3 MB
• GL default extra: 168.3 MB
• VAAPI Intel: 13.6 MB
- Codecs (openh264): 976.5 KB
- Application Locale: 125.4 KB
- Kooha application itself: 2.2 MB
Total: ~1.1 GB
Native RPM Package:
- Package size: 2.2 MB
- Uses existing system libraries
Total: 2.2 MB
For someone mindful of disk space, this felt like overkill for a simple screen recorder. My system already had most of these dependencies installed. Why download them again?
Taking the Plunge into Package Building
That's when I had an idea: why not build Kooha natively for Fedora? With zero RPM packaging experience but plenty of curiosity, I set out to create a native Fedora package. Thankfully, with the help of claude.ai, I was able to do this in under an hour.
The first challenge was creating a spec file - the recipe that tells the RPM build system how to create the package. Here's what I learned:
# Basic information about the package
Name: kooha
Version: 2.3.0
Release: 1%{?dist}
Summary: Elegantly record your screen
# Licensing and meta
License: GPL-3.0
URL: https://github.com/SeaDve/Kooha
Source0: %{url}/archive/refs/tags/v%{version}.tar.gz
# Build requirements
BuildRequires: meson
BuildRequires: ninja-build
BuildRequires: cargo
BuildRequires: rust
BuildRequires: appstream
BuildRequires: pkgconfig(gstreamer-1.0)
BuildRequires: pkgconfig(gstreamer-plugins-base-1.0)
BuildRequires: pkgconfig(gtk4)
BuildRequires: pkgconfig(libadwaita-1)
BuildRequires: pkgconfig(glib-2.0)
# Runtime requirements
Requires: pipewire
Requires: gstreamer1-plugins-base
Requires: gstreamer1-plugins-ugly-free
Requires: gstreamer1-plugins-bad-free
Requires: pipewire-gstreamer
Requires: xdg-desktop-portal
Requires: gtk4
Requires: libadwaita
%description
Kooha is a simple screen recorder with a minimal interface. Record your screen
in an intuitive and straightforward way without distractions. Features include
recording microphone and desktop audio, support for WebM, MP4, GIF, and Matroska
formats, and the ability to select a monitor or portion of the screen to record.
%prep
%autosetup -n Kooha-%{version}
%build
%meson
%meson_build
%install
%meson_install
%check
appstreamcli validate %{buildroot}/%{_datadir}/metainfo/*.metainfo.xml
%files
%license COPYING
%doc README.md
%{_bindir}/%{name}
%{_datadir}/applications/*.desktop
%{_datadir}/metainfo/*.metainfo.xml
%{_datadir}/icons/hicolor/*/apps/*.svg
%{_datadir}/glib-2.0/schemas/*.gschema.xml
%{_datadir}/locale/*/LC_MESSAGES/*.mo
%{_datadir}/dbus-1/services/*.service
%{_datadir}/%{name}/resources.gresource
%changelog
This spec file tells the RPM build system everything it needs to know about the package: what it's called, what version we're building, what dependencies it needs, and how to build it. Getting the dependencies right was particularly tricky - I had to understand both what was needed to build the application (BuildRequires) and what was needed to run it (Requires). With the spec file in place, I could then set up the build environment:
rpmdev-setuptree
dnf install rpmdevtools rpm-build meson ninja-build \
gstreamer1-devel gtk4-devel libadwaita-devel
rpmbuild -ba kooha.spec
What followed was a fascinating journey into the heart of Linux packaging. Along the way, I discovered three things that changed how I think about Linux applications:
First, I gained a deep appreciation for the freeDesktop.org ecosystem. Building a native Linux desktop application isn't just about the code - it's about integrating with a rich framework of standards and specifications that make the Linux desktop experience seamless.
Second, package management turned out to be an intricate dance of dependencies. Understanding the relationship between build-time and runtime requirements, and how they all fit together, was both challenging and enlightening.
Finally, I came face-to-face with the challenges of cross-distribution compatibility - which gave me a whole new appreciation for why the original author chose Flatpak in the first place.
Automating the process
I decided to not end at just building the application locally. I wanted to automate the process so that
I had a way to ensure that I had the latest updates
I had a reference in case I (or others) encountered a similar challenge in future
Others could benefit from it, and perhaps adapt it to other distros
I therefore went ahead and built an automated RPM package builder for Kooha. The automation process involved creating GitHub Actions workflows to:
Check for new Kooha releases periodically
Build fresh RPM packages when updates are available
Create GitHub releases with the built packages
The result was a fully automated system that keeps the RPM package updated with minimal maintenance overhead. The RPM packages are available on the project's GitHub releases page. If you're interested in contributing or learning more about RPM packaging, the project's README provides detailed information to get you started.
Learning Through Building
This project taught me so much about Linux application development:
The complexities of building for different distributions
The role of desktop integration through FreeDesktop.org standards
The importance of automated builds and release processes
The beauty of being able to customize and build software to suit your needs
The Sustainability Challenge
Working on this project opened my eyes to the challenges of maintaining open source software. What looks simple on the surface often requires significant ongoing effort:
Continuous Updates: Every new OS release, dependency update, or security patch requires testing and potentially updates
User Support: Responding to issues, helping with installation problems, and documenting solutions
Infrastructure Costs: Build systems, hosting, and distribution all have associated costs
Time Investment: Maintainers often work on these projects in their spare time
This brings us to an important point: open source software needs financial support to thrive. While the software is free to use, its development and maintenance aren't free. There are several ways to support the open source ecosystem:
Direct Support:
Donate to projects you use regularly
Subscribe to maintainers' GitHub Sponsors or Patreon accounts
Pay for support or additional features when offered
Indirect Support:
Report bugs and provide detailed feedback
Contribute documentation or translations
Share and promote projects you find valuable
Help other users in community forums
The Power of Open Source
What strikes me most about this journey is how it exemplifies the power of open source. When faced with a problem, I had the freedom to:
Examine how the original application was built
Create a different distribution method
Share my solution with others
Learn about Linux packaging in the process
While Flatpak is an excellent solution (and I now understand why the Kooha developer chose it), having alternatives is what makes open source special. Someone might prefer the Flatpak version for its portability, while others might want an RPM (or deb, etc.) version for its smaller footprint.
Most importantly, this experience taught me that sometimes the best way to learn is to dive in and build something, even if you've never done it before. The Linux ecosystem might seem complex, but it's also incredibly rewarding to explore and contribute to.
Getting Involved
If you're inspired to explore Linux package development:
Start Small: Pick a simple application you use and try building it from source
Learn the Tools: Familiarize yourself with packaging tools like rpmbuild or debuild
Join Communities: Participate in distribution-specific packaging groups
Support Projects: Consider supporting Kooha and other open source projects you use
Have you built packages for Linux before? What was your experience like? Please share your thoughts in the comments below!
