> During the course of the last 20 years the Linux community hasn't even
> managed to agree on one unified format for binary packages, which is a
> positively trivial exercise compared to coming up with a standardised and
> stable desktop ABI.
Let me correct that for you:
During the course of the last 20 years the developers whining about Linux distributions have not managed to agree on a single deployment rule. When asked to fix their s* by distributions they complain that distributions propose slightly different solutions, do nothing, and then are offended that distros take upon themselves to do some damage control and that Linux users by and large use the distribution fixes instead of the genuine broken-by-design binaries that they self host. Not only they've been unable to agree on and write their own rules, but they've been unable to decide which pre-written distro ruleset to adopt.
They continue to beat the deb/rpm differences dead horse when every technical comparison in the past decade showed both formats were functionally equivalent and had the same requirements, they complain about distro patching that supposedly fragments the market when distros essentially reinvent the same fixes or trade the same patches (you could even find Linux distro patches in OpenSolaris when it was still alive), they complain about distro release dates when all major distros release about the same time nowadays to take GNOME/KDE into account, bug trackers are full of the same requests by users of different distributions and the response is always 'I could fix this but $otherdistro may demand something else' (replace $otherdistro by whatever distro which has not found the time to point out the problem yet).
Suse happily copied Fedora packaging guidelines on its own wiki because they were better than no rules (when Suse had not written its own rules yet), and comparing Debian/Fedora guidelines is a case of parallel evolution with very similar solutions.
Those developers could make distributions irrelevant in a blink by releasing software that didn't need massaging for mass deployment. Except that would mean tackling the issues distros solve today, would identify the same pain points distro point out now, and the whole point of the exercise is to postpone integration and avoid paying the technical debt of past mis-decisions.
In fact those developers quite often deny there is a need for integration and associated rules, justify this denial by pointing the supposedly minuscule Linux market share, and always forget to mention the even more abysmal market-share of their own not-integrated direct developer-to-user binaries. No, they prefer to compare to the Windows/OSX/Android/whatever ecosystem, and conveniently forget that those ecosystem have rules too, and that their owners are at least as directive as Linux distributions (the usual excuse is 'but $x does not ask for $y like Linux distributions', forgetting $x asks for $z when Linux distributions do not care about $z).