I agree with you that there is nothing new to this sort of thing, but why does there need to be a common standard? Personally I'd prefer a few different standards with their own ideas competing instead of a single one that is just some compromise between the different ones.
"Let a thousand blossoms bloom" isn't the right approach for package management. A package manager is IMHO not the place for creativity, competition, bikeshedding, and fragmentation because that's what we have already. The focus should be on winning devs to actually use a package format, so that users can more easily install software without upstream devs needing to maintain yet another format.
We're not talking about thousands of formats...only a few formats make up the most popular formats around.
I see nothing special about package managers that makes competition undesirable. I think creativity and competition are good for package managers. Besides why does an upstream dev need to maintain these new formats? They can choose to support whatever they want.
Personally I don't understand why this is a big deal. Any fragmentation is the result of reasonable people disagreeing on the best approach. The plethora of different ideas is a feature of the ecosystem not a bug.
I see nothing special about package managers
that makes competition undesirable.
The most common rationale I hear for using Snap/Flatpak/AppImage over traditional deb/rpm is that the fragmentation of the latter is burdensome [1].
One of the main claims of Flatpak is "The days of chasing multiple Linux distributions are over. [...] Create one app and distribute it to the entire Linux desktop market." [2]
If you are designing something to solve the problem of fragmentation, and by so doing you increase fragmentation, you've achieved the opposite of your goal.
Just to be clear, I see no reason to use Snap/etc. over older packaging solutions. However I wouldn't necessarily agree that this automatically increases fragmentation. If Snap/etc. were to support Ubuntu, debian, Redhat, etc., they could provide maintainers a single target across many systems. Then the maintainer could just target that solution and be done. Of course this requires them to win that developer marketshare, but if they believe they can, then they believe they can achieve their goals without fragmenting they system.
I personally don't see the need for these systems, but I still see absolutely nothing special about packaging. No maintainer has to support these new packaging methods if they want. If some developers believe they can introduce new and improved packaging systems, I wish them luck.
Because developers want to target the whole Linux desktop segment without having to reproduce the packaging process several times. Has nothing to do with whether the format is better or worse as long as it is consistent. Fortunately, gems like FPM have attempted to address this issue.
One of the main advantages of Linux and all the different distributions is the freedom the users have to have a system that matches his or her needs. This has been the case for decades. There has never been a single packaging solution and I see no need for one. Of course packagers want their lives to be easier, but the request to target the whole Linux desktop segment without reproducing the package process is pretty unreasonable given that different users simply want different packaging systems. Developers should weigh the advantages/disadvantages of supporting (say) Ubuntu or CentOS just as they do for Mac and Windows.
If you want to innovate, innovate in user-facing areas. This kind of tinkering is the reason Linux didn’t take off anywhere, except for back end servers, where it won because of being free and because of Linus’ community building skills.
Android had to lock it down almost completely to gain acceptance.
They even call themselves "next generation" while encouraging the 1990s "setup.exe" deployment model: no centralized management of security updates, no vetting process from a trusted 3rd party, large applications.
To be fair, that's true for all new-fangled package managers including Docker, and exactly what's painful about them: that they're trying to solve a problem (that of mixed libaries on Linux distros) by bypassing shared lib loading, thereby defeating the purpose of shared library loading (that of preventing stale/insecure libs) in the first place.
If that was the goal, why not just distribute statically-linked binaries or distribute into /opt package prefixes, which would be the natural solution? I guess there's no problem that can't be solved by another layer of abstraction, except the problem of too many layers of abstractions. Again, https://xkcd.com/927/ comes to mind.
