The problem with Linux packaging in large organizations
One of the challenges of implementing and utilizing Linux across a large organization—an organization where there are many different people with significantly different computing needs—is … packaging.
Seriously. Packaging is a big problem.
Just as an example:
Let’s say you are in charge of IT for a 1,000-person organization. Your server needs dictate that you’ll need (or at least likely want) a server-oriented Linux distribution with some sort of paid support contract. Easy enough. You can choose Red Hat Enterprise or SUSE Linux Enterprise. Server needs met.
But what about the marketing department? Does an enterprise-grade, server-focused distribution make sense for all of them? Probably not. Maybe you can standardize on one of the media production-focused distributions—or perhaps the community-driven sides of the enterprise distribution you already chose for your servers.
Either way, your package versions are likely to differ. Possibly a little. Possibly a lot. Forcing you, if you want to have any level of standardization across your organization on versions of specific apps (say, your Office Suite and web browser), to maintain a custom repository for at least one of the two Linux distributions you’ve selected thus far (if not for both).
Then what happens when your SysAdmins, software developers and testers want to use—whatever distribution they want to use? Ever try telling a programmer he has to use a specific version of a specific operating system? If there’s a quicker way to a full on mutiny, I’ve never seen it. So, now you’ve likely got Debian, Ubuntu, Mint, openSUSE and Fedora installations scattered throughout your organization.
Plus that one guy running Arch and/or Gentoo who just won’t stop reminding you that Arch/Gentoo is the best. We all know that guy.
What are you going to do? Maintain a repository for every piece of software your company relies upon (which could be an awful lot) for a half dozen different distributions of Linux?
That’s a lot of work. Possibly a huge amount of work. But the alternative is standardizing on a singular version of a singular distribution for every workstation used by every person in your organization. For many, that’s just not an option.
So, maintaining packages for multiple distributions, it is!
2 options for maintaining packages for multiple Linux distributions
As I see it, there are only two real ways to go about this (without going insane):
Going this route you could, in theory, package a single AppImage (which is, essentially, a self-running .iso that contains all the necessary resources to run that particular application on any supported Linux variant) that supported the majority of the modern distributions out there.
Or you could stick to traditional packaging and repositories unique to each distribution, but utilize something like the Open Build Service to automate the building of those packages (and automatic maintaining of the repositories) across all of those distributions, as well.
There are benefits and drawbacks to both. Building an AppImage is simple from the point of view that you need to build only one “package” and you’re done—no need to learn about packaging formats of various distributions. But on the flip side, this doesn’t solve the issue of making sure all workstations are up to date.
Sticking with traditional repositories and package formats takes care of the updating problem for you. It’s tried and true. But you’ll need to learn more about cross-distribution packaging. Even when using something like Open Build Service, which makes this all a lot easier and much easier to maintain, you still have a slightly bigger learning curve ahead—though a likely worthwhile learning curve if keeping everything up to date is a concern.
Maybe one day the entire Linux world will come together and standardize on a single package format across all distributions. And on that fateful day, we will all maintain a single repository structure and system to make keeping every computer, no matter the distribution, easily up to date and in sync.
Until that glorious (and ridiculously delusional) day occurs, we have AppImage, FlatPak and Open Build Service to make our lives just a little bit easier.