Distributions
Having the Linux kernel all by itself on a computer is pretty much useless. Imagine a system that boots, and then does nothing else. Pretty much a paperweight, right?
Now, add some basic CLI tools and a shell, add a DHCP client, some graphical server, a desktop environment, an audio player, and a browser. You now have something exciting to use!
Thankfully the kernel and all these components are ready for you to use, compiled, tested, and packaged in one of many Linux distributions, making the installation and assembling of your system an effortless task.
Packaging
But before getting there, those packages had to be prepared by someone. This person had to learn how to obtain the sources, list all the dependencies, compile the binaries, choose which files would go where, and catalog its contents. This person then gets known as the package maintainer.
And this work is not where it stops. Because after packaging it once, the maintainer has to keep up with every release and update. Every related change to the build process, new dependency added, newly published files, and even how to make the version tagging fit into the distribution patterns.
Each distribution has its tooling for helping the maintainer. Some distributions prefer constraining the packaging process, so it strictly follows their decisions and philosophies. In contrast, some prefer to target simplicity, keeping the maintainer’s worker as minimalist as it needs to be.
Source packages
How much easy does it get? Distros like Gentoo, ArchLinux, and Alpine leave this premise to the extreme. Their source-package only requires a file, written in the same language as most of the system’s scripts: Shell script.
ArchLinux’s principle philosophy is “Keep it Simple, Stupid.” and is visible in their “PKGBUILD“. And to learn how to write one, all you need is to visit its page in ArchWiki. In there, you find all the variables needing exposure, how to write the packaging build steps, and are pointed on standards and guidelines for further publishing and maintaining a package.
ArchLinux’s PKGBUILD
Considering that this is not a new thing, Gentoo has a simple package-source for ages, ArchLinux’s PKGBUILD has shown an impressive adoption rate. The project has the giant community-managed AUR library with over 2500 packages. Besides that, most of its packages are found forked in it’s derivates distributions like Manjaro, Endeavors, and architectural variations projects like ArchLinuxARM and ArchLinux32.
And this list increases, and there are BSD distributions that adopt this format, while inspired with it, there is Alpine Linux’s APKBUILD. Even on Windows, you’ll find these in the POSIX-compatible MSYS2 environment.
Advantages
And that hype is understandable. Keeping a transparent and simplified packaging recipe makes it easy to add cross-compiling features, customize enabled features, add custom patches and forks, and keep any package up-to-date. Easy enough for ArchLinux users to be known for using packages updated with the latest master branch commit.
Etienne Juvigny is a popular community package maintainer in the ArchLinux. Entirely out of the ArchLinux official repositories and even out of the community-driven AUR, and using his nickname Tk-Glitch, he maintains a few out-of-standard PKGBUILDs for gaming enthusiasts. The users using his source-packages always have the latest kernel, Wine, Valve’s Proton, and other tools with the best patches applied over it. Even for non-stable releases like the kernels’ release-candidates. For example, the new NVIDIA’s Vulkan-dev drivers release took only five minutes to end up pushed into TkG’s repositories.
Different approaches
And if a distro prefers not to give the maintainer this much liberty, it can end with a solution as AlpineLinux did. Its packaging build stack enforces more rules than ArchLinux like it’s package versions must match a strict pattern. The user doesn’t need to learn this while writing the APKBUILD, as the make command will produce errors in an understandable language during packaging.
The MSYS2 source package’s codebase carries this simplicity to Windows machines. You can grab a PKGBUILD from ArchLinux, and with small adjusts (and sometimes patching), have it build on a Windows machine, including 32 bits and 64 bits binaries.
Capabilities
Being simple doesn’t mean it’s not feature-full. ArchLinux’s PKGBUILDs describe and can do source caching, splitting debug symbols from release-purposed binaries, signature proofing, and reproducible builds. The sources and building process can be different depending on the system’s CPU architecture. Patching, building, and packaging are in separate steps. Release, make, and optional dependencies are separated. Package versions are not strict, and this way, a PKGBUILD serves to build different versions of the same code. The simplicity is just so that all these features are managed by a single line (each) in the code.
AUR
This way, it’s common to find many projects that are yet to see a stable public release already installed in ArchLinux users’ machines. Unrelated contributors push these packages’ sources in the AUR project, and through commentaries and flagging each other packages, they keep their packages ecosystem fresh and working.
When a package follows the official team’s standards and has enough votes, a Trusted User adopts and brings it into the official repositories. Similarly, when a package loses its purpose in the official repo, it’s resubmitted in the AUR, going back to community management and extending its life.
Conclusion
Via this simple package production, ArchLinux receives much community-effort for still-in-development packages like Wayfire and projects that don’t extend attention and support for others distros like the Pantheon environment.
The PKGBUILDs, its build tooling, and the package manager from ArchLinux, help smaller projects like MSYS2 maintain their numerous packages.
For the Linux ecosystem, nothing better than keeping the life of our friends, the maintainers, as easy as it can be. It helps saving time for supporting more programs and updating them faster.
