Allow to change /usr/share/factorio in the binary

[Fwiffo]

As mentioned in Linux config directory should follow XDG Base Directory Specification, this is a bit more exotic but it helps packaging (note: not distributing) Factorio for Nix and maybe even other distros (IIRC Debian policy would be something like "/usr/share/games/factorio").

Essentially what I'm suggesting is to change the "/usr/share/factorio" literal so that there is additional space available for different paths to fit in, eg. like this:

Code: Select all

#define SYSTEM_DATA_DIR "/usr/share/factorio\0Hello Nix people, you" \
                        " can use this space to write your own path" \
                        " into the binary.                    #end#"

The reason is that on Nix there is no "/usr/share" nor there is anything in "/usr" (except "/usr/bin/env" for compatibility) and every application/library/whatnot gets its own dedicated directory in the Nix store, so instead of "/usr/share/factorio", the path would be "/nix/store/yb2ymjlvmx150qfkgy3rj7cy3njhl7lz-factorio-1.1.8/share/factorio". Since the binary only has space for 19 bytes (plus null byte), just changing the path isn't possible without overflowing.

And yes, I'm aware that it could be changed via wrapper script, but especially this wrapper introduces additional moving parts that could fail at runtime. Additionally shell wrappers also make running via ltrace or gdb a minor annoyance.

Again, this is a bit more exotic and I wouldn't be mad if this isn't implemented, since there are other ways™ to find the additional space needed within the binary.

[ptx0]

personally, i wouldn't expect wube to change anything to suit NixOS as it deviates so far from what is considered normal/acceptable Linux system practices that this kind of breakage is just something that you should expect.

[Rseding91]

You can just set the folder the game uses through the config.ini file and config-path.cfg file. https://wiki.factorio.com/Application_directory

[Fwiffo]

personally, i wouldn't expect wube to change anything to suit NixOS as it deviates so far from what is considered normal/acceptable Linux system practices that this kind of breakage is just something that you should expect.

It's about Nix (the package manager) in general, not just NixOS (the distro) and I'm aware that it's exotic (even though Nix is also used on Mac OS to my dismay ), but maybe they're considering it anyway since it could also make it easier for other package managers and/or distros. For example I had related "feature" requests for some other games, where I was asking to avoid opening files r/w in the game's data files and most of them eventually implemented it - although not because of my request but because they ran into issues with various A/V software on Windows.

So yes, I guess even when speaking about GNU/Linux in general, we're speaking about a minority and despite that fact they choose to support it anyway (and also pretty well compared to most other games), so maybe they're considering the above as well, given that the change is very minor and even less involving than the XDG stuff

But again, I can't (and don't) expect them to do it, given that probably no other game has something like this.

You can just set the folder the game uses through the config.ini file and config-path.cfg file. https://wiki.factorio.com/Application_directory

I'm aware of this, which is why I mentioned this in my initial post already:

And yes, I'm aware that it could be changed via wrapper script, but especially this wrapper introduces additional moving parts that could fail at runtime. Additionally shell wrappers also make running via ltrace or gdb a minor annoyance.

Of course, if there would be a well-defined way to patch in the path of the config file into the binary, it's also fine, but then again it boils down to roughly the same variant as mentioned in the initial post.

[ssilk]

In my eyes nix has to provide a way to map those paths. Patching a binary sounds so dirty, I could not believe it. On Amiga I knew software, that - if it finds out it was patched - did overwrite sectors on the floppy, instead of reading - just to prevent hackers from replacing the authors name with theirs. Ok, it’s really unfair, and so on, but you cannot really trust software without the code.

I know some of the core nix people personally, I will ask them about this, when I meet them (hopefully in summer).

[Fwiffo]

In my eyes nix has to provide a way to map those paths. Patching a binary sounds so dirty, I could not believe it. On Amiga I knew software, that - if it finds out it was patched - did overwrite sectors on the floppy, instead of reading - just to prevent hackers from replacing the authors name with theirs. Ok, it’s really unfair, and so on, but you cannot really trust software without the code.

Well, this is one of the weak points of NixOS (note: not Nix) and newbies often struggle with this: If you download a random ELF executable and just want to run it, it most certainly won't run at all because the interpreter is hardcoded to something like `/lib64/ld-linux-x86-64.so.2` and there is no `/usr/lib` to find the libraries needed.

So with Nix, we just patch those binaries and, well, use wrappers if necessary.

Alternatively you can also run the program in an FHS user environment, which provides a filesystem namespace with all the Nix store paths mapped to file hierarchy standard locations, but that's even more ugly to work with and comes with additional runtime overhead at startup.

Again, and as mentioned, for Factorio we already have a wrapper and I admit it's just my personal obsession to get rid of them, the patch mentioned in the other thread is something I keep in a downstream repository but I won't add it to nixpkgs, because it would mean that only a single person can maintain it. If the above would be implemented in Factorio, we could get rid of the wrapper in upstream nixpkgs and I can also drop the (downstream) patch for good

[ssilk]

I think that’s a legal interest.
I’ll move this back to suggestions.

Even that I know, that it has not much chance to be implemented. That market is too small.