Fragmentation of Linux and impact on packaging

Linux fragmentation (meaning many distros out there), while positive in some ways (spurring innovation, customization and freedom of choice), makes it more difficult to properly address diverging packaging methods between them. There are services online that make it possible to manage packaging for Linux, and some are quite easy, while some are (incredibly) difficult to use. What's in packaging? For one, the list of third party packages that your package depends on. Then, there's a list of files (executables, libraries, man pages, etc.) that you want installed and their locations.There could be some actions you'd like to perform, such as setting up SELinux policies after the files have been installed. So, overall it's not that difficult or complicated. And all the different packagers basically do the same thing. But when you are faced with a number of competing packagers, each with their own set of rules (some of which are difficult to understand), and with rules that tend to change, then it becomes a mess. You start to feel like you're dealing with many different Operating Systems. Adding to this feeling of fragmentation is the fact that the same third-party package that you may be using is named differently on different distros. And the versions used may vary wildly, so they may not even be compatible. Each of these packages, in addition, is often customized to some extent. So then Apache uses "a2..." utilities on Ubuntu, but you have to edit config files on RedHat. It's unclear as to how to avoid this fragmentation mess without adding yet another packaging format and regulating customizations. So it would seem there's enough energy to look into major distros only. "Major" is a fluctuating term obviously based on current market share, but it also depends on the amount of work needed to maintain spec files and build dependencies as well as availability of online services that make the final binary build easy. With that in mind (and things may change one way or the other), Golf is now available for Ubuntu and Fedora-like distros (see below). We're looking to introduce Golf to Debian, and hopefully that will be added soon. The list of distros you can (currently) install Golf on using dnf (available from Fedora COPR): Amazon Linux Redhat 10 Redhat 9 Fedora 42 Fedora Rawhide Mageia 9 OpenSUSE Tumbleweed The list of distros you can (currently) install Golf on using apt (available from Ubuntu LaunchPad): Ubuntu 25 Ubuntu 24 Ubuntu 22 Ubuntu 20 Please be patient while Golf transitions into a more manageable state regarding packaging and availability. Source code is of course available for anyone who wants to use Golf anywhere, however Golf development and testing is likely to be limited to a certain smaller number of Linux distros.

Apr 4, 2025 - 03:55

Fragmentation of Linux and impact on packaging

Linux fragmentation (meaning many distros out there), while positive in some ways (spurring innovation, customization and freedom of choice), makes it more difficult to properly address diverging packaging methods between them. There are services online that make it possible to manage packaging for Linux, and some are quite easy, while some are (incredibly) difficult to use.

What's in packaging? For one, the list of third party packages that your package depends on.

Then, there's a list of files (executables, libraries, man pages, etc.) that you want installed and their locations.There could be some actions you'd like to perform, such as setting up SELinux policies after the files have been installed.

So, overall it's not that difficult or complicated. And all the different packagers basically do the same thing. But when you are faced with a number of competing packagers, each with their own set of rules (some of which are difficult to understand), and with rules that tend to change, then it becomes a mess. You start to feel like you're dealing with many different Operating Systems.

Adding to this feeling of fragmentation is the fact that the same third-party package that you may be using is named differently on different distros. And the versions used may vary wildly, so they may not even be compatible. Each of these packages, in addition, is often customized to some extent. So then Apache uses "a2..." utilities on Ubuntu, but you have to edit config files on RedHat.

It's unclear as to how to avoid this fragmentation mess without adding yet another packaging format and regulating customizations.

So it would seem there's enough energy to look into major distros only. "Major" is a fluctuating term obviously based on current market share, but it also depends on the amount of work needed to maintain spec files and build dependencies as well as availability of online services that make the final binary build easy.

With that in mind (and things may change one way or the other), Golf is now available for Ubuntu and Fedora-like distros (see below). We're looking to introduce Golf to Debian, and hopefully that will be added soon.

The list of distros you can (currently) install Golf on using dnf (available from Fedora COPR):

Amazon Linux
Redhat 10
Redhat 9
Fedora 42
Fedora Rawhide
Mageia 9
OpenSUSE Tumbleweed

The list of distros you can (currently) install Golf on using apt (available from Ubuntu LaunchPad):

Ubuntu 25
Ubuntu 24
Ubuntu 22
Ubuntu 20

Please be patient while Golf transitions into a more manageable state regarding packaging and availability.

Source code is of course available for anyone who wants to use Golf anywhere, however Golf development and testing is likely to be limited to a certain smaller number of Linux distros.