Build it Yourself: When a 2MB Solution Beats a 1GB Installation

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.

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:

# 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 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:

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, 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!