[deanCommie]

A serious question for any Linux-heads here, no insult intended.

How is it possible that there are ELEVEN different possible package managers that need to be supported by an installation script like this?

I can understand that some divergences in philosophical or concrete requirements could lead to two, three, or four opinionated varieties, but ELEVEN?

Does that mean that if I want to write an app that runs on Linux I should also be seeking to support 11 package managers? Or is there something unique about tailscale that would necessitate it?

edit: Thank you for the responses so far, but noone has yet answered the core question: WHY are there eleven of them?

[antif]

Tailscale may be unique as a network appliance that users like to run on a lot of different equipment.

Used GPT-3.5 to summarize these and tried to edit the response for brevity. Pardon any hallucinations here. Looks like it's mostly just different OSs all running their own software publishing/distribution portals. Lot of NIH maybe.

""" 1. apt: Debian, Ubuntu.

2. yum: Red Hat / replaced by DNF.

3. dnf (Dandified YUM): Red Hat, Fedora / successor to yum.

4. tdnf (Tiny DNF): lightweight DNF for minimalist distros.

5. zypper: SUSE/openSUSE.

6. pacman: Arch Linux, Manjaro.

7. pkg: FreeBSD.

8. apk: Alpine Linux.

9. xbps Void Linux.

10. emerge: Gentoo Linux.

11. appstore: Apple / iOS, macOS. """

[stavros]

It's like anything else, it depends on how many people you want to get. Apt alone will get you 50%. Add pacman and that's another 30%. Yum is another 15%. Nix is another 2%. Foo is another 0.3%, bar 0.1%, and so on and so on. (Numbers are made up).

You don't have to do anything, it's just about how convenient you want to make it.

[kcb]

Surely pacman is nowhere near as popular as yum/dnf.

[pjerem]

> edit: Thank you for the responses so far, but noone has yet answered the core question: WHY are there eleven of them?

Because Linux is "just" a kernel that happens to be used by different OS. Linux is just the program that runs binaries amongst your computer, it’s not a package manager or an OS.

There is no official cooperation between different Linux OS. People developing package management at Suse or Redhat (which are commercial companies) aren’t the same that are developing APT at Debian foundation. Odds are that they don’t even know each others.

Look, Android is based on Linux but they have their own package management because most of the existing ones weren’t compatible with what they wanted to achieve.

It’s the same with other vendors : while package managers looks like they are mostly doing the same thing, they all had their own requirements that justified their creation.

Anyway as a developer you mostly don’t have to package your app yourself. It’s the job of either the distribution developers themselves (in fact that’s most of the work in making a "distribution": they package and distribute software) or in some organizations like Suse or Arch, this job can also be done by the community which allows more up to date package.

[deanCommie]

It turns out my actual question is "Do we really need this many different Linux distributions" and I'm sure this will sound even more wrong but it really feels like the answer is no.

OK different ones for different hardware devices, sure.

But I asked ChatGPT of the difference between openSUSE and Debian (since you mentioned those) and everything listed seems like it could be just variants within the same OS not a fundamentally different OS

> Package Management: > openSUSE uses the Zypper package manager and supports the RPM package format. > Debian uses the APT (Advanced Package Tool) package manager and supports the DEB package format.

This comes back to my original question - they need different package managers because the OS's are different, the OS's aren't different because they wanted different package managers

> Release Model: > openSUSE typically follows a fixed release model with regular releases of a stable version, like openSUSE Leap, which has a predictable release cycle. > Debian follows a more flexible "when it's ready" release model. There are three main branches: stable, testing, and unstable.

you could have unstable, testing, stable, and then on top of that have a predictable stable release cycle. These aren't incompatible with each other.

> Philosophy: > openSUSE is known for its strong integration with the open-source community and its adherence to the principles of the Free Software Movement. It emphasizes stability and ease of use. > Debian is known for its commitment to free software principles, as outlined in the Debian Free Software Guidelines (DFSG). It prioritizes stability, security, and freedom.

This just feels like a ChatGPT hallucination. It sounds like both are focused on Free Software. That said, I suppose noone is stopped from creating a Linux OS extremely focused on FSM, a commercial one not-at-all interested in FSM, and one somewhere in between.

> Default Desktop Environment: > openSUSE offers various desktop environments, including KDE Plasma and GNOME, but its default desktop environment may vary depending on the edition (Leap or Tumbleweed). > Debian offers a wide range of desktop environments, including GNOME, KDE Plasma, Xfce, LXQt, and more. Its default desktop environment is GNOME.

Like the package manager, inverted cause and effect.

> Community and Support: > Both distributions have active and supportive communities, offering forums, mailing lists, documentation, and other resources for users seeking help or guidance.

> System Configuration: > openSUSE uses YaST (Yet Another Setup Tool), a comprehensive system configuration tool that allows users to manage various aspects of the system through a graphical interface. > Debian relies more on manual configuration files and command-line tools for system administration, although there are also some graphical tools available.

I wonder what YaST uses underneath, I bet it's a series of...configuration files :)

No reason why both couldn't work on the same OS.

[Elucalidavah]

If you write an app that runs on Linux, you should support flatpak, and (for bonus points) nix.

The rest should be done by the distros' maintainers.

[cassianoleal]

For something like Tailscale, running as a Flatpak would require the user to relax the sanbox boundaries, assuming it would work at all!

It's probably easier to script up the installation via package manager. You also get the benefit of upgrades along with the rest of the system.

Furthermore, I haven't seen a single instance of Flatpak being used to install applications on headless servers.

I also don't know many sysadmins who would be happy that each application they install in their servers will come with a full set of dependencies rather than being dynamically linked to the base system.

[thomastjeffery]

Why? Because there is. Every package repository has a community of maintainers who make sure a package is compatible with their OS/distribution. That's just the way each linux distro solves this problem. It's worked out pretty well so far, despite the sheer number of redundant packages.

Why not? This kind of script is a generally bad idea, because it's hoarding the responsibility of package maintenance. The better solution is to maintain a working package (better yet, convince someone to maintain it for you) for each distro's public repository, good documentation on their wiki, and working links to that documentation in your readme.

Why not not? Despite being a bad idea, it's not a hard idea. The implementation of this script is likely easier to manage than doing it the proper way.

--

Now if you really want to feel upset, start looking at build systems...

[fsmv]

Normally it's not your job to package it yourself the distro maintainers do that

[nick238]

If you're writing proprietary software and trying to get it out there so you can get paying users, it's your job.

[bpfrh]

Because there is unfortunately no "linux"

Sure, there is the linux kernel in different version and patch states, but everything else including on how to manage software(package manager) is something the distribution decides.

As there is no standard and for historic reasons, different distributions choose different package managers.

If you want to support linux you normally decide on which distribution you want to support and more importantly which version of them.

The big ones out there are probably ubuntu, fedora and arch.

Then you can decide between building packages for the different package managers or just build a static/dynamic binary that works on the distros and runs on them.

You can also use flatpack and snap which makes it easier to support different versions of the same distribution, but you run in a sandbox and afaik lower level access to the graphic stack(games) is a mess.

Yeah it is a mess, but at least most distributions have the same service/bootup manager

[anddam]

The only proper approach is to come up with a twelfth package manager that will encompass all the other eleven.

https://xkcd.com/927/