GOG is still getting used to linux and i'm ok with their learning curve.
part of the issue may be that the two versions of Linux that GOG supports allow the user to switch which graphical user interface(user desktop) to use/install. Mac & Windows operating systems have defined GUIs/embedded file manager APIs that cannot be switched or changed.

linuxmint 17 LTS has 3 different desktop options(Cinnamon, KDE, LXDE).
Barring basic Xserver compatibilty, the Cinnamon, KDE, LXDE desktops each have different linux software libraries,different utility tools and have different file managers, embedded drivers, codec support, etc.

most of GOG's linux supported titles appear to be running in WINE, so the GOG linux team probably haven't dealt with a ton of command line scripting involving binary file checks/delta patch scripting. getting used to that is probably contributing to the reason why standalone linux patches have been delayed.

No actually there isn't many Wine-packaged titles. Flatout 2 and the D&D games that were just added this week are the only ones I remember right now. There are more Dosboxed games, and even more native ones I think (pretty much all the indies are native).

Fedora had deltas for awhile, but they disabled them - correct me if I'm wrong but I don't think Debian or Ubuntu have ever supported delta packages.

I know it's technically feasible but there hasn't been much in the way of standardization effort that I'm aware of. If the distributions themselves don't do it, I don't think it's fair to fault GOG for not getting it working.

Desktop environments and file managers are entirely unrelated to what we're discussing here; Linux is a far more modular, less centrally-integrated OS than Windows, and these tools are equivalent to end-user applications in Linux. Dependencies are generally only to libraries and lower-level interfaces like GUI APIs and messaging busses, and there really aren't any necessary dependencies at all for doing delta patches: all you need is code that can read in two files and output a third. A statically-linked build of a tool like xdelta, which could be easily included in the patch archive, is all that would be necessary.
I'm more than happy to use the Windows versions of games that are using WINE anyway, so this isn't an issue for those. This problem really applies only to Linux-native game distributions. GOG's already written some pretty complex shells scripts to bundle with the game archive, and a delta patch tool is trivial in comparison.
I haven't seen a single .deb package available on GOG. Every Linux title I have in my library is a tarball that includes GOG's own scripts for setup, with no package manager involved at all. Even if they did decide to go with Debian packages, it would still be trivial to release deltas of the .deb files themselves, especially since they're not even hosting a repo, and you've got to download the packages manually anyway.

(And, BTW, you can include post-install deployment scripts in a Debian package, so it would be entirely feasible to create a .deb that "installs" the delta files to a temporary directory, then invokes e.g. xdelta to apply them to the original game files. In fact, this would work even better than a tarball, since target paths and game-version dependencies would be enforced by the package manager.)

Ah, they do seem to be phasing out the deb installers. My Duke Nukem 3d still has one, but I'm pretty sure Flatout 2 use to have one and it doesn't now, and none of the recently added DND games have one. My mistake for not paying attention lately.

If they're going with tarballs anyway then yes some sort of graphical GOG installer / patcher for linux that statically builds in or depends on xdelta makes sense, along with binary diff files for patches.

Edit:
statically building in xdelta doesn't make sense, it's not a lib. So either including the binary or depending on it.

I'm surprised that they're doing so, given that they're explicit about only targeting Ubuntu and derivative distros. Tarballs are a better way to publish distribution-independent software, but will probably generate at least marginally more support requests.
Static linking refers to building an executable with the libraries it depends on compiled into its own binary. This is the opposite of dynamic linking, which looks for the necessary libraries on the system at runtime; if they're not there, the program won't run. Using a statically-linked build of xdelta would ensure that it will run on all target systems, regardless of whether the necessary libraries are installed or if they're the correct versions -- that way, it will always work when the patch script invokes it, regardless of the user's system configuration.

Nope. The two Flatout games were the first ones to only have tarballs. I believe this is true for all WINE wrapped games. The Witcher 2 have more to do with the size than its wrapper.

I have 31 Linux games in GOG and only 6 of them are missing the .deb package. Those are Baldur's Gate, Baldur's Gate 2, Planescape Torment, Flatout 2, The Witcher 2 and Wasteland 2. Of those only one is native, one is eON wrapper and the rest are Wine.

AFAIK all Dosbox games have a .deb package.

There is some reason behind that decision but I don't think they're fading out the .deb packages.

As I said in my edit though, xdelta is an executable not a library so it can't be static linked, just included in the package. Incidentally I am a software developer :-)

Not really... ;)

First, xdelta is both an executable and a library (libxdelta2) that can be embedded in another program (C or whatever, there are Python bindings for it). The executable is just a tiny wrapper over the library (parsing command-line options, ...).

Then, while you can statically link _with_ a library (which means, embedding the library binary code inside your executable), you can statically link _an_ executable (which means, embedding all the libraries it requires within itself).

If you just provide a copy of "/usr/bin/xdelta", it'll just fail to execute on any computer that doesn't provide it's own copy of "/usr/lib/libxdelta.so.2". So to make the patching process painless, you'll have to provide a statically linked version of "/usr/bin/xdelta" that embeds libxdelta (and other required libs).

GOG is really screwing Linux users with the latest 1.3 patch. Only 6 files changed and the patch
is just 126 kilobytes. These are all Unity files which fixed a crash on exit for me.

If you have 1.2.0.6 and the game is working OK for you then you may want to save yourself the 11GB
download. You won't be missing any game features.

Eh?

You didn't happen to see the release notes?

Some of those might be Windows-specific, but I'm quite sure there's a lot more than just crash on exit that's fixed on Linux too. And there's some added stuff too like the tips at loading screens.

Cool, wasn't aware of libxdelta2

Pedantry. It's clear from the context that we're talking about statically linking (lib)xdelta to some sort of GOG utility.

I looked into libxdelta, it's GPL2, so GOG would have to open source their patcher to link it. No idea if that's a deal breaker for them.

Not really, there are two options open to gog if they want to leverage xdelta :

1. Write their own executable, which will have to be statically linked with libxdelta.

2. Write a shell script (or an executable, or whatever) that comes with a statically linked version of xdelta, xdelta being executed by the script/executable. In that scenario, a "statically linked version of xdelta" takes all its meaning.

That would be the best yes, but they can also provide an xdelta binary and just exec it (option 2 above), that wouldn't break the GPL requirements.

This is sort of what I was originally thinking, given that GOG's Linux releases seem to include a lot of setup and launcher scripts, but no native executables.

None of the scripts have any GUI elements thus far, but I'd expect it'd be equally trivial to use something like Zenity if they had to have one.

I get the feeling that there are few or no Linux users at GOG, and putting together scripts in a way that's relatively simple and straightforward for experienced Linux users is a time-consuming task over there.