Not sure I can avoid this with duplicity/rdiffdir, I might have to look at other tools for bypassing this.

You’re welcome, but actually Sude did most of the work on the last one ;)
https://www.gog.com/forum/pillars_of_eternity/linux_unofficial_patches/post57

I built a new patch using uid/gid=1000 (no more 'users' group).
The direct download and the .torrent can be downloaded from the usual place, with Sude’s build still available in the 'Sude-builds' directory.

For a patching method not messing with uid/gid, I think I have to move away from duplicity/rdiffdir, so at this point any suggestion is welcome.

librsync provides rdiff, which is what powers rdiffdir. rdiffdir itself is just a friendly wrapper for recursively applying rdiff (via a tarball). You could bypass it, with a zip file as a container [compression turned off]. Zip is not aware of the UNIX permissions, so the problem goes away.

I've tested the following workflow on my local machine:

zip -r -0 - ./old-version | rdiff signature - old-version.sig

zip -r -0 - ./new-version | rdiff delta old-version.sig - new-version.delta

[*compress the delta with 7z here*]

zip -r -0 - ./old-version | rdiff patch - new-version.delta new-version.zip

The only downside is that unzip doesn't support stdin; so you can't pipe the output of the "rdiff patch" process to it directly. Which means the user will need to have enough hard drive space to hold two copies of the game, until he can delete the old version and extract the new one.

Sounds interesting, I’ll give a try to the method you suggest.

Okay, I think I’ll keep two versions of the patch: one with rdiffdir (most single-user systems won’t have problems with it), and one with zip+rdiff with a warning about the extra space needed.

Alternatively, you could just have those people create a new user at UID 1000. ;)

The process would be something like:

#first time only
sudo useradd -u 1000 [patchuser]
sudo passwd [patchuser] [password]

mkdir /tmp/poe
mv [PoE folder] /tmp/poe/
chmod 777 -R /tmp/poe/[PoE data]

su [patchuser]
<apply patch to /tmp/poe/[PoE data]>
exit

mv /tmp/[PoE data] [PoE folder]
chmod 744 -R /tmp/[PoE data]

Hi.I think you should consider git too. It can be intimidating at first, but if you have time to invest on it, it'll be very rewarding when your project grows. And you will make things pretty easy for us users. Here some tips:
$ cd /some/where/poe.git
$ git init .
Initialized empty Git repository in /some/where/poe.git/.git/
$ git add .
$ git commit -m 'Initial release.'

This will create the git repository (will take ages!!)
What you should do, at least imho, is to create a branch for every patch, and then export it.
$ git branch
* master

Create a branch for patch 1.1.0.2:
$ git branch v1.1.0.2
$ git checkout v1.1.0.2
Switched to branch 'v1.1.0.2'
$ git branch
master
* v1.1.0.2

Now copy the new files here. When finished:
$ git add .
$ git commit -m 'Patched to version 1.1.0.2'

To create the patch:
$ git format-patch master
0001-Patched-to-version-1.1.0.2.patch

Compress and upload it. Please use something more standard like bzip2 or 7zip. I'm sure you have good reasons to use other programs, but not everybody uses debian/ubuntu and it can be difficult to find some programs.

Users will just have to run:
git apply --check ../0001-Patched-to-version-1.1.0.2.patch
And if there are no errors:
git apply ../0001-Patched-to-version-1.1.0.2.patch

Users must install git but they don't need to create the repository.

As far as I'm aware: git doesn't create deltas of binary files when patching or syncing; so those patches couldn't be legally distributed...

oh ok.. Just forget my post then..

Next patches will probably be compressed using 7-Zip.

I wrote a script to create and apply patch sets, you can find it on github:

https://github.com/neovatar/patchmonger

It should make things a bit easier. Binary diffs are done with xdelta3 and LZMA compression, which should yield sufficient compression for the patches. The patchmonger script will create a tgz file with the patchset data and an embedded patchmonger, so that it is enough to download the patch tgz, extract it and run the embedded bash script.

The script is using bash, grep, sed (which are included in almost all Linux distros by default). The only thing you probably need to install is xdelta3 with LZMA support. Usually you can install it easily from your distros repository (e.g. via "sudo apt-get install xdelta3" on Ubuntu).

The script should work with all GOG Linux games tgz installers (e.g. Wasteland 2).

Nice project, I’ll probably spend my week playing with it!
Looks really easy to use when applying the patches, so it may well become the "official" distribution method for the next patches.

I created two patch sets:

gog_poe-patch-1.0.0.1_1.1.0.2.tgz is game version v1.0.3.503
gog_poe-patch-1.1.0.2_1.2.0.3.tgz is game version v1.0.4.540

I used these sets to patch my version and it was identical to the downloaded 1.2.0.3 complete tgz.

If somebody wants to beta test, feel free to do so.

You can find the patchmonger sets here:

http://stuff.neovatar.org/patchmonger_poe/

Good work creating a script for xdelta3.

But there is a legal problem with the "pmnew" process: it's not transformative, the files are simply copied over with "pmnew" appended on the file name. Anyone can recover them by renaming the files. In theory: over time someone could collect enough patches to create a working copy of the game (granted: there are faster ways to steal games).

While the end result of rdirdiff is the same; the fact that the delta is created on the entire dataset: makes a strong argument for the process being transformative. I know of no technical means [that currently exists] to recover the new files without having a complete copy of the target files.

Sorry if it sounds like I'm splitting hairs. Looking at it from the perspective of a rights holder: anything that makes a copy of the data directly, is going to run afoul and have legal problems.

While that's correct, from the formal point of view, even a transformative patch can't be redistributed without permission from the owners. Or at least that's a common requirement of most user agreements that come with games. But what you are saying is that transformative patch is less likely to upset the owners, since original can't be recovered from it.

Yes.

But I think we can even go a step further and say in this instance: one process creates a derivative work, while the other makes an exact copy (abet with a new file name). The former may fall under fair use, but the later definitely does not. [Disclaimer: I'm not making an official statement. Just my opinion, based on my limited knowledge at this time. ;) ]

I still want to applaud tseliger for taking the time to write an awesome script. When I first started thinking about this: I had the same idea [except my version used diff to discover what files were new/changed/missing]. Which is when I ran into the dilemma of how to deal with new files simply being copies.