There is Windows files also distributed as zip files, just as unusable.
There is Windows files also distributed as zip files, just as unusable.
Never link to a deb or rpm as the primary “download”. It should be a flatpak or app image and then an advanced options section for distro specific packages.
tar.gz is opaque in a different way - the solution would be more like an interpreter - something which has a good guess how you should install/run the file.
There is the issue also of integration with the distribution, this is a problem with distribution apis - package maintainers are invested in their formats and distribution list not solid apis with which to interact. If you could build against such a set of Apis you could bundle an interpreter which just knows what to do.
Tar.gz is a hell of a lot simpler than any other format, it's not the issue, it's the desktop distros who are underfunded/at fault.
Yes, this is true.
But it is no help on RPM-family distros, or Arch-family ones, or Alpine or Void or whatever.
> and do all the right things.
No, mostly, it won't. Because the file won't be added to the OS's list of repositories and it will never get updated.
This is not automatic behaviour, but it can be: Google does this right. Do this with Chrome or Google Earth or whatever and it just magically happens, and that is the Right Thing™.
IME: it's always application devs who are upset about this, not users.
[1] That will happen in time anyway. This is a flagship app.
[2] I would not expect any distro to include a major version in its stable release. So, even if they do that, it will take months to percolate out.
[3] When it happens, it will need an OS version upgrade.
This is a standalone app release, not an OS release. It is in many OSes and it will make its way to them in time. You are conflating 2 different things.
The question we are discussing here is: I run T'bird on my own box, and I want to try the new version; how do I do that?
There are 2 possible solutions to this: either provide distro-native packages (as Google does; this is mainly appropriate to proprietary apps, which T'bird is not); or, provide some kind of cross-distro package. Since both Snap and Flatpak need support tools installed, and AppImage does not, that makes AppImage the best choice, IMHO.
Snapcraft and Flathub will do their own thing in time.
On which note, T'bird 102 is already on Snapcraft, but it does not pick up existing T'bird settings or profiles.
OTOH do not forget that Arch is a family of distros now, not a single distro, just as Debian is.
In fact I suspect that it is the 2nd biggest family of distros, after Debian.
Debian encompasses many dozens: Ubuntu, plus dozens of Ubuntu derivatives including Mint, Elementary, PopOS, ZorinOS, Linux Lite etc.; LMDE; Devuan; MX Linux; SpiralLinux; etc. etc.
Arch now encompasses at least Manjaro, EndeavourOS, Garuda and more. https://wiki.archlinux.org/title/Arch-based_distributions
But that is not the point.
The point is that _tens of millions_ are running non-Debian-derived distros, mostly ChromeOS and CloudReady/ChromeOS Flex.
Offering a .deb package is _not_ a useful approach to offering a generic Linux package, no.
FWIW, I have tried both the Snap and AppImage versions of TB 102.
Both were very easy to install. The problem is that Snap confinement meant that TB could not see my existing profile. I just got the first-run wizard.
This did not affect the AppImage, which is working well.
And like you said, Google does it. They do it with a single deb you click on.
I feel like package managers on distos are a thing that kinda make people forget that applications can be distributed “normally” outside this chain.
However, for better or for worse, it is not the Linux way.
Maybe it should be, but it isn't.
I can't think of a single Linux app that self-updates this way. I suspect that on most distros, permissions issues would prevent it.
I also suspect that if it were easy, Google would have done it. It is not a company that does things the hard way for fun.
Packaging apps as distro-native packages isn't trivial but there's tons of existing tooling for it. Ditto for hosting repos.
So what Google did is package stuff so that it adds its own repos when you install it, and then it is left up to the OS to keep it updated.
That to me says that that was an easier job than writing self-updating Linux apps, like Chrome on Windows or on macOS.