# Build it Yourself: When a 2MB Solution Beats a 1GB Installation ## The Catalyst: Fedora 41 and Wayland When I upgraded from Fedora [40](https://fedoramagazine.org/announcing-fedora-linux-40/) to [41](https://fedoramagazine.org/announcing-fedora-linux-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](https://news.itsfoss.com/fedora-41-gnome-wayland/). As someone who regularly used screen recording tools, this change immediately affected my workflow - I suddenly couldn't use my trusty [Peek](https://github.com/phw/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](https://github.com/SeaDve/Kooha), a modern screen recorder designed with Wayland in mind. ![Kooha's clean, modern interface makes screen recording simple](https://cdn.hashnode.com/res/hashnode/image/upload/v1734477986629/fc0c8529-281b-41e6-84c9-89743c65e05f.png align="center") Perfect! But there was a catch: it was only available as a [Flatpak](https://flatpak.org/). 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: ```plaintext 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](https://rpm-software-management.github.io/rpm/manual/) packaging experience but plenty of curiosity, I set out to create a native Fedora package. Thankfully, with the help of [claude.ai](https://claude.ai/), I was able to do this in under an hour. The first challenge was creating a [spec file](https://fedoramagazine.org/how-rpm-packages-are-made-the-spec-file/) - the recipe that tells the RPM build system how to create the package. Here's what I learned: ```plaintext # 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: ```bash # Setting up the RPM build environment rpmdev-setuptree # Installing build dependencies dnf install rpmdevtools rpm-build meson ninja-build \ gstreamer1-devel gtk4-devel libadwaita-devel # Building the package 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](https://www.freedesktop.org/wiki/) 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](https://github.com/engineervix/kooha-rpm/). 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](https://github.com/engineervix/kooha-rpm/releases). 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: 1. **Direct Support**: * Donate to projects you use regularly * Subscribe to maintainers' GitHub Sponsors or Patreon accounts * Pay for support or additional features when offered 2. **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: 1. Examine how the original application was built 2. Create a different distribution method 3. Share my solution with others 4. 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](https://manpages.debian.org/unstable/dpkg-dev/deb.5.en.html), 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: 1. **Start Small**: Pick a simple application you use and try building it from source 2. **Learn the Tools**: Familiarize yourself with packaging tools like `rpmbuild` or `debuild` 3. **Join Communities**: Participate in distribution-specific packaging groups 4. **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!*