Autopackage was shot down because, architecturally, it was an eldritch horror.
I disagree here, even when it had technical problems it was capable to be used by several high profile projects, GAIM and inkscape used it successfully. Also, even when it had technicla problems why these were not fixed or an alternative approach proposed? Because, Autopackage was shot down as it was questioning the general propagandized linux architectural "superiority", not because of the real or exaggerated technical reasons.
It was easy for applications to use but it was an eldritch horror in how it accomplished what it did. Hence, push-back from the platform side of things.
Yes, Linux can be frustrating, but a lot of it stems from the segment of the developer population that believes it's better to take forever to get a solution than to enshrine an ugly one and have to support it until the end of time for compatibility reasons.
The reasons are slightly different and comes from: "we have the source, so just recompile" (no stable ABI) and "caring and protecting compatiblity is boring, designing new things is fun" (no API at all). In general, some kind developer elitism.
Good point. There is an epidemic of that. (I switched from KDE 4 to LXDE because of it and jwz wrote about
the same thing in GNOME.)
Hence the "If you don't want to wait, bundle it so we don't have to support it" attitude.
*hmmm* can't remember that the classical distro infrastructure ever proposed or provided distro-agnostic binary bundeling mechanisms. The only thing I can remember is the breaking of the loki installer, the prevention of FatELF, the general brokenness of the ELF format regarding .SO topics, the continous binary breakage of the glibc....
I'll give you FatELF and distro packaging. Those are both unarguable cases of nasty politicking.
However, I wasn't considering them relevant because I don't see offering two binaries and a "detect the arch" launcher script as a problem, given that most games need a script anyway to work around the fact that Windows ports usually assume that $PWD will indicate the parent directory while Linux launchers use it to indicate the user's documents directory.
As for glibc, it's maintained by Ulrich Drepper, the man who said "Stop wasting people's time! Nobody cares about this crap." in response to a patch to fix the skewed random distribution of strfry(). There's a reason Debian uses the EGLIBC semi-fork now.
I really hope that, as musl-libc
continues to fill out its peripheral feature set, someone decides to add some compatibility symbols and get distros to migrate to it. It explicitly takes a forward-compatible approach. (It's already pretty complete, as the chart on the site shows.)
Or you mean per distro packaging? which is of course, insane.
No argument there. Icculus and I both agree that only fools or people with a lot of time on their hands offer distro packages.
I think Trine 2 is the most elegant Linux offering I've yet seen. (Unpack the tarball and the game has a first-run wizard which offers to install a launcher menu icon)
...but my install.sh script
which users can double-click to add a launcher and desktop icon is also a good way. (The developers just fill in 8 variables in the script and it does the rest.)
Also, I prefer tarballs to binary installers because, for stuff not managed by the system package manager, I prefer the MacOS-style "Just delete the folder to uninstall" approach.