I have to reply to this. :D Sorry.

Even easier: Go to your software repository (Software-Center, Synaptic, or plain apt) and look for the game (i.e. type the name in the search box). It's in the repositories and you can readily install it from there. No need to build your own deb package.

You’re absolutely right.
I hesitated because of this before publishing this script, but I finally settled with a publication and a link to the Debian package page in the usage guide. (maybe I should add one to the Ubuntu and Mint pages too?)

You should see it as a way to test my claim to provide a perfect integration with the system: compare the game installed from the official repositories to the game installed via my scripts, and if you can’t tell the difference it means I’ve done my job right ;)

(well, actually mortalius wrote this one, not me, so he’s the one deserving praise if everything works as intended)

Yes, you're right, too, of course. I agree that sometimes it gives a good feeling to prove that it is possible. :) In that sense: thank you for posting the instructions.

One thing though: I used to like deb-packages a lot (or rpm for that matter). 'Used to' because I feel that for third party software tarballs are actually the way to go. My impression is that it is very difficult to make deb-packages which work on -- for example -- Ubuntu 12.04 and continue to work on Ubuntu 14.04 without modification. A tarball plus a file explaining which dependencies have to be met are a more stable solution. I think at least, but your mileage may vary, as they say.

./play.it .deb packages should work on *any* APT-based distribution, no matter which version.
And if one does happen to not work as expected on some distribution/version, you just need to report the bug here on GOG forums and I’ll have no sleep until it’s fixed ;) There’s a 2.0 version of the ./play.it architecture in the works (what you see here is 1.13 version, and is most probably the finale 1.x version), and one of its planned features is to allow a choice between .deb or .tar for the built package (+ various compression formats, most probably at least gzip and xz).
That’s actually a base to support more package formats in the future. I won’t build support for other format than .deb and .tar myself, but I’m open to contributions and I’ll try to make the inclusion of new formats as easy as possible (which includes of course the redaction of a comprehensive documentation).

Wow, that's great. :) I will keep that in mind. Thank you for your work. In the case of ./play.it .deb packages: they will probably work anywhere because they're self contained -- i.e. without any dependencies? I was more referring to other third party software, which is relying on libraries which need to be there in certain versions. A deb package can have a list of dependencies and if the system can not meet them automatically (for example if Canonical decides to give the exact same library a different package name; which they did for certain libraries), the package can not be installed. I have encountered that issue in the past, which required me to repackage that software product (it was a game in this case). That was a pain in the neck, and since then I resort to tarballs only. But I understand that this isn't for everyone. I actually prefer it ... firing up a terminal window, cd to /opt and untar -- done (most of the time anyway). Other people prefer to be able to use the package manager and I support that. Linux is all about choice. That is great news. :) I think your ./play.it architecture is wonderful. It will make life easier for lots of people. :) Thank you for your work.

The ./play.it .deb packages do rely on system packages. But what you can do when writing a dependencies list, and most publisher don’t do it for some reason, is providing a list of alternatives instead of a single package.
As an example, most WINE games packages depend on 32-bit version of WINE, but they will accept any of these packages to fulfil this dependency:
wine32, wine-bin, wine1.6-i386, wine1.4-i386 or wine-staging-i386

That way the dependency can be met at least on Debian Squeeze to Jessie, any version of Ubuntu packaging WINE 1.4 or 1.6, and Mint version based on these Ubuntu versions.

To make sure the ./play.it packages do know of an extensive list of alternatives, I’m mostly relying on feedback from the users of said scripts. I can’t of course test all of these distributions myself ;)
Well, I could, but in that case I wouldn’t have time to write new scripts anymore…

True ... or almost. What you can't do this way is make the package future-proof, so to speak. What good is a list of alternatives when it doesn't contain the alternative needed for Ubuntu 16.04? (Hint: we can't know about that alternative at the moment.) That was my dilemma. I had a deb package built for Ubuntu 12.04 where it worked beautifully. In Ubuntu 14.04 Canonical decided it would be much cooler not to use libmono-wcf3.0-cli but rather libmono-wcf3.0a-cli instead. Does the same thing but breaks all dependency lists. That's what I am trying to convey.

The alternatives in the dependency list don't help in this case. Only repackaging (with of course this very alternative in the depencency list) worked. But that is of course no viable solution. It is a bad idea to repackage every time a new version of any distribution gets released. If the library hadn't been in the dependency list (instead only some version of mono) it would have worked. That's my point.

I can do mass modifications on all my scripts at once. That’s what I did when I learnt that Ubuntu doesn’t use the same packaging for WINE than Debian does.
It would take half a second even with thousands of scripts.

The real solution of course would be for distributions like Ubuntu to make a smart use of the 'Provides' field… But "teaching" developers is a bit out of scope for the ./play.it project ;)
(beside of course teaching curious people how to write their own scripts, which is totally part of this project)