Topic: Nightly .deb packages for Linux

[jamespetts]

I have just started testing a system to create .deb packages for Linux (Ubuntu, Debian, Gentoo, etc.) for Simutrans-Extended's latest nightly builds. I have not tested this yet, so I should be interested in anyone's experiences of how this works.

This includes the graphical executable, makeobj, nettool, Pak128.Britain-Ex and Pak128.Sweden-Ex (both the latest nightlies from the half-heights branch). They are available below.

Nightly .deb packages

I should be grateful if people could let me know whether this works.

Edit: I think that these will need some work to get these in the correct paths so that it runs properly from the command line.

[Vladki]

I have tried the deb package on Debian Jessie (8.x current stable), but it does not install because of unmet dependencies. You specify dependency on libpng, but the package is libpng12-0. More over there should be much more dependencies. dh_shlibdeps may be helpful to make the dependencies right.
Also putting all files in /usr/local/bin/simutrans/ is imho not the "right way". There should be only executables in /usr/local/bin/. One way would be to put everything in /opt/simutrans/ and symlink the executables in /usr/local/bin/ or /usr/local/games/.

Perhaps the easiest way would be to get the source package from debian - simutrans is already there, just it is standard version 111.2.2, and modify the package to contain simutrans experimental. Also the package is split into binary (arch dependent), data (arch independent) and paksets. Just do apt-get source simutrans, and fiddle with it.

[jamespetts]

Thank you for that feedback. I am entirely new to creating Debian packages, so do forgive me if I have missed a few things.

For reference, here is the control file:

Code: [Select]

Package: simutrans-ex
Version: 12.9000
Section: base
Priority: optional
Architecture: amd64
Depends: libpng
Maintainer: James E. Petts <jamespetts@yahoo.com>
Description: Simutrans-Experimental

And here is the shell script that I use to create the package:

Code: [Select]

echo "Package creater for Simutrans-Ex"
echo
# TODO: Set the version numbesr automatically somehow
major_version=12
minor_version=9000
revision=14

name=simutrans-ex_$major_version.$minor_version.$revision
dir_name=/usr/share/games/package/$name

mkdir $dir_name
mkdir $dir_name/usr
mkdir $dir_name/usr/local
mkdir $dir_name/usr/local/bin

echo
echo "Copying executables"
cp -rf /usr/share/games/nightly/simutrans-experimental/simutrans $dir_name/usr/local/bin
cp /usr/share/games/nightly/simutrans-experimental/build/default/simutrans-experimental $dir_name/usr/local/bin/simutrans/simutrans-experimental
chmod 777 $dir_name/usr/local/bin/simutrans/simutrans-experimental
cp /usr/share/games/nightly/simutrans-experimental/build/default/makeobj-experimental/makeobj-experimental $dir_name/usr/local/bin/simutrans/makeobj-experimental
chmod 777 $dir_name/usr/local/bin/simutrans/makeobj-experimental
cp /usr/share/games/nightly/simutrans-experimental/build/default/nettool/nettool $dir_name/usr/local/bin/simutrans/nettool
chmod 777 $dir_name/usr/local/bin/simutrans/nettool

echo
echo "Copying pakset files"
cp -rf /usr/share/games/nightly/simutrans-pak128.britain/pak128.Britain-Ex $dir_name/usr/local/bin/simutrans/
cp -rf /usr/share/games/nightly/Pak128.Sweden-Ex/Pak128.Sweden-Ex $dir_name/usr/local/bin/simutrans/

# TODO: Find a way of downloading the latest translation texts here

echo
echo "Creating control file"
mkdir $dir_name/DEBIAN
# TODO: Make the version numbers in control automatic
cp /usr/share/games/package/control $dir_name/DEBIAN

echo
echo "Building package"
cd $dir_name
cd ..
dpkg-deb --build $name
echo
echo "Moving package to the download directory"
mv /usr/share/games/package/$name.deb /var/www/downloads/nightly/packages
echo
echo "Complete"

If you would like to post improved versions of both of those, that would be exceedingly helpful.

[Vladki]

Well the trick is that you should not make your own script, but produce a "rules" file, which is a Makefile that does all what's needed - compile, and make the package.
I may try adapting the debian package to sim-ex, but it might be better and faster to get in contact with debian maintainers of simutrans package. Contacts here: https://tracker.debian.org/pkg/simutrans

[jamespetts]

Where would I find the rules file in the directory to which you linked?

[Vladki]

The best way is to enable deb-src lines in your /etc/apt/sources.list, e.g:
deb http://debian.mirror.dkm.cz/debian/ jessie main non-free contrib
deb-src http://debian.mirror.dkm.cz/debian/ jessie main non-free contrib
(similar for ubuntu, just change your mirror and version)
apt-get update
apt-get install dpkg-dev
apt-get source simutrans

The last command will download and unpack the "source" package. You will get a simutrans-120.x.x folder with the simutrans-standard sources, but with an extra "debian" directory, where all packaging stuff is. Also a few debian specific patches will be applied, most notably the paths where to find stuff (~/.simutrans/...; /usr/share/games/simutrans/...), and also config.default is provided.

The easy part is to remove patches you do not want to be applied, and rename the package in debian/control, check if debian/rules is OK. Then the main issue will be to replace the standard sources with experimental. There are also some helper targets in debian/rules to get fresh sources from SVN@SF, so that would have to change to github.

[jamespetts]

I have just modified my control file to change libpng to libpng12-0. I do not currently have time to look into using rules, but can somebody check after to-morrow morning to see whether this now works? I should be most grateful.

[ras52]

Are the nightly .deb builds still supposed to be working?  The simutrans-experimental binary in the 25 April build (filename simutrans-ex_12.9000.14.deb) is dying on start up with the message: "Incompatible pak file version for Simutrans-Ex, number 3".  This happens with all three paksets that are supplied in the .deb: pak128.Britain-Ex, Pak128.Britain-Ex and Pak128.Sweden-Ex.  (I assume there are not supposed to be two copies of pak128.Britain-Ex, differing only in their capitalisation.) In case it's of help debugging, the title bar gives the simutrans version as "Simutrans 120.1.2 Experimental Nightly development build 12.9000 - rb565bf4". 

[jamespetts]

This is odd - it looks as though the binary version in the nightly .deb builds is a much older version, and is now incompatible with the latest pakset version. I will have to look into this when I get a chance. Thank you for the report.

[ras52]

it looks as though the binary version in the nightly .deb builds is a much older version, and is now incompatible with the latest pakset version.

Thanks.  That was exactly the problem.  The version of the simutrans-experimental binary in the .deb is from 11 Feb 2017 according to the version string embedded in the binary.  However if I overwrite it with the the nightly simutrans-extended linux-x64 binary downloaded from bridgewater-brunel, it works just fine.  As 11 Feb is the day you renamed it from "Experimental" to "Extended", and as the binary in the .deb is still called the former, I'm guessing the problem is just that you're copying the old binary into the .deb, so hopefully this is an easy one to fix.

(I also note that the .deb is a missing dependency on the libsdl2-2.0-0 package.)

[Roboron]

I've created an Arch Linux package for Simutrans Extended in the AUR. I've tried following the decisions made for the Simutrans package maintainers in [community] repos, but I first believed that Simutrans Standard paksets were compatible with Extended. Since that is not the case, I've decided to take some decisions:

• Simutrans Extended executable is patched to look for data in /usr/share/games/simutrans-extended instead of /usr/share/games/simutrans
• It is also patched to look for config in ~/.simutrans-extended instead of /.simutrans
• It also includes a desktop file with the same icon as Simutrans Standard.

I'm planning on submitting also paksets - both for Standard and Extended. Indeed, I already did push to the AUR simutrans-extended-pak128.britain (and added it as an optional dependency). The decision to split Simutrans Extended directories from Simutrans Standard directories therefore has been taken in order to install the paksets separately - this way the end user won't open an incompatible pakset by mistake when launching Simutrans Standard/Extended.
Please, let me know if you dislike any of this decisions.

P.D.: It is in my TO-DO list yet to automate the process of bumping the version of the packages everyday so it can follow the nightly release cicle (if there are any changes ideally).

[Matthew]

I've created an Arch Linux package for Simutrans Extended in the AUR.

Roboron, thank you for doing this! I think that one of the biggest barriers to spreading Simutrans is how difficult it is to install and stay up to date, so this is really helpful.

I've tried following the decisions made for the Simutrans package maintainers in [community] repos, but I first believed that Simutrans Standard paksets were compatible with Extended. Since that is not the case, I've decided to take some decisions:

• Simutrans Extended executable is patched to look for data in /usr/share/games/simutrans-extended instead of /usr/share/games/simutrans
• It is also patched to look for config in ~/.simutrans-extended instead of /.simutrans
• It also includes a desktop file with the same icon as Simutrans Standard.

I'm planning on submitting also paksets - both for Standard and Extended. Indeed, I already did push to the AUR simutrans-extended-pak128.britain (and added it as an optional dependency). The decision to split Simutrans Extended directories from Simutrans Standard directories therefore has been taken in order to install the paksets separately - this way the end user won't open an incompatible pakset by mistake when launching Simutrans Standard/Extended.
Please, let me know if you dislike any of this decisions.

I think splitting Standard and Extended directories is a good decision, especially now that Standard paksets are completely incompatible.

However, I respectfully disagree with your other two decisions.

Firstly, I think there is an important decision about the location of the binaries and data. Both Arch and Ubuntu (following Debian) put Simutrans-Standard in /usr/share/games. Whether that is the right place for those distributions is a decision for their maintainers. But for the Simutrans-Extended project, it is a bad choice. The man page for /usr says "should hold only shareable, read-only data". The Filesystem Hierarchy Standard says (my emphasis) "it. .. should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." But in practice, playing Simutrans-Extended requires nightly updates. It is not read-only.

I am not saying this because of an obsession with obscure Linux rules. The problem is that modifying files in the /usr hierarchy requires root access. Root access should not be necessary for playing a transport game. A real-life example: I have been teaching my nephew to play Simutrans. At the moment he's so young that he needs me to sit by him all the time. But when he's a little bit older, he should be able to update Sim-Ex without needing root access. In fact, he should be able to download and install Sim-Ex without needing root access. Root is for sysadmins; playing Sim-Ex (which in real life requires patching Sim-Ex) is not a sysadmin task.

This way of thinking may be surprising to old hands at Linux. The title "usr" gives many people a vague idea that all programmes for users are supposed to go in /usr. That's not what the standards say and that's never been the case in reality either. Steam gets this right and places all its games in /home/.steam. We should follow their lead and install Simutrans-Extended in the /home directory.

I don't know whether the rules of AUR allow you to do that. But fixing the .deb package is on my to-do list* and I plan to use /home. What do others think of that idea?

Oh, and the second disagreement? I like to use the pak128.Britain-Ex icon for the .desktop file. But that's a very personal decision. 

P.D.: It is in my TO-DO list yet to automate the process of bumping the version of the packages everyday so it can follow the nightly release cicle (if there are any changes ideally).

That would certainly be an improvement

* As the first step, I successfully tested a revised .deb on a clean VPS last year .... and then deleted the only copy.

[Vladki]

James, i disagree with you. Files from packages should never end up anywhere in /home. They should go to /usr. They are there for all users of the computer. If you have the permission to install packages (root, sudo) then you can update as well.

[Roboron]

Roboron, thank you for doing this! I think that one of the biggest barriers to spreading Simutrans is how difficult it is to install and stay up to date, so this is really helpful.

Indeed, that is my main motivation to do this. Simutrans paksets are usually scattered across the forums and following updates is not easy, specially when we talk about Extended. A proper packaging will improve discoverability and ease of install/update!

The man page for /usr says "should hold only shareable, read-only data". The Filesystem Hierarchy Standard says (my emphasis) "it. .. should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." But in practice, playing Simutrans-Extended requires nightly updates. It is not read-only.

What it means with "it must not be written to" is that the user must NOT modify those files (i.e. to apply some user-specific config) - since other users depend on them! It doesn't mean that the data needs to be written one time and then never be updated. There is indeed nightly updated software in the AUR and it is always installed in /usr...

But you have a good point! Reading those docs gave me the impression that "/var/games" is a better fit to Simutrans (both Standard and Extended) data than "/usr/share/games". At least most of it. See, most of Simutrans data should be modifiable by the users - it's the only way to add mods, scripts and other stuff! But because the decision of Debian maintainers users can't modify content in /usr/share/games and therefore can't use mods, add their music, etc... If we use "/var/games" for game data we would solve this problem. I'm looking forward to further discuss this change and contact with maintainers.

The This way of thinking may be surprising to old hands at Linux. The title "usr" gives many people a vague idea that all programmes for users are supposed to go in /usr. That's not what the standards say and that's [url=https://foone.wordpress.com/2019/03/15/thread-and-usr-thread/]never been the case in reality either. Steam gets this right and places all its games in /home/.steam. We should follow their lead and install Simutrans-Extended in the /home directory.

This is in direct confrontation with the notion of a package. A package, by definition, is a program that is installed system-wise, available for all users, and therefore can't and must not be installed in the /home directory. I strongly advice you against making a package that uses /home. What you can do to achieve that is using a game manager like Lutris, which install games by default in ~/Games (only for the current user, of course). Simutrans Standard is already available on Lutris, including a script to download paksets. Maybe my next step should be making Simutrans Extended also available via Lutris (though this doesn't solve the updating paksets issue).

I don't know whether the rules of AUR allow you to do that. But fixing the .deb package is on my to-do list* and I plan to use /home. What do others think of that idea?

Indeed this is my first time making an AUR package, and as Arch Linux user the first thing I did is head to the wiki and read the guidelines. Let me quote you what the Arch package guidelines page of the wiki says about packaging:

    Package files should follow these general directory guidelines:

    /etc    System-essential configuration files
    /usr/bin    Binaries
    /usr/lib    Libraries
    /usr/include    Header files
    /usr/lib/{pkg}    Modules, plugins, etc.
    /usr/share/doc/{pkg}    Application documentation
    /usr/share/info    GNU Info system files
    /usr/share/man    Manpages
    /usr/share/{pkg}    Application data
    /var/lib/{pkg}    Persistent application storage
    /etc/{pkg}    Configuration files for {pkg}
    /opt/{pkg}    Large self-contained packages

    Packages should not contain any of the following directories:
        /bin
        /sbin
        /dev
        /home
        /srv
        /media
        /mnt
        /proc
        /root
        /selinux
        /sys
        /tmp
        /var/tmp
        /run

These are not guidelines for the AUR but for Arch Linux packaging in general. Broking those guidelines could result in the deletion of the package...

Oh, and the second disagreement? I like to use the pak128.Britain-Ex icon for the .desktop file. But that's a very personal decision. 

I'll look into that 

James, i disagree with you.

You mean Matthew right?

[Phystam]

How about pak128.sweden-ex and pak256-ex? Probably they could be available.

[Roboron]

How about pak128.sweden-ex and pak256-ex? Probably they could be available.

Phystam are you jealous because I packaged pak128.britain-ex before your magnificent, splendid, majestic pak256-ex? (･ω<)☆

I can make available pak128.sweden-ex and pak256-ex at any time now, it's a fast an easy edit. However I first wanted to gather some feedback about the packaging of simutrans-extended. And I think it was a good idea, Matthew expressed some valid points I should reconsider with the maintainers about how the packaging of Simutrans has been done before submitting more paksets.

[Phystam]

 Thank you;) (however, I'm not an Arch Linux user...

[Vladki]

    James, i disagree with you.
You mean Matthew right?

Sure...

IMHO files should go this way:
/usr/games/ - just the simutrans(-extended) and makeobj(-extended) - just the executables, nothing else
/usr/share/games/simutrans(-extended) - everything else from the package - paksets, default config, music, scenarios, translations,...
~/.simutrans(-extended) - user's own data - saves, screenshots, addons, paksets not available as packages, user modified configs

IMHO there is no need to use /var/games  (wargames ?)... Usually there are just highscore files shared with other users of the computer, but I don't see any use for that.
An option would be to look into /usr/local/share/games/simutrans(-extended) for extra paksets, addons and such stuff, that is not packaged, but can be shared with other players. Also write access for non-admin users could be allowed for this directory.

[Phystam]

According to simmain.cc, the default data directory is /usr/share/games/simutrans-ex/ . Probably it is better, isn't it?

[Vladki]

-ex or -extended, whatewer...

[Roboron]

/usr/games/ - just the simutrans(-extended) and makeobj(-extended) - just the executables, nothing else

I agree. I don't see much problem with executables going to /usr/bin, but your suggestion is more FHS compliant  :-)

/usr/share/games/simutrans(-extended) - everything else from the package - paksets, default config, music, scenarios, translations,...

I disagree (mostly). I'm going to quote FHS:

The /usr/share hierarchy is for all read-only architecture independent data files.

Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally).

Game data stored in /usr/share/games must be purely static data. Any modifiable files, such as score files, game play logs, and so forth, should be placed in /var/games

Now, let's take a look at what is in /usr/share/games/simutrans right now



Content in folders ai, config, font, music, script and themes are supposed to be modifiable by users (as well as paksets). But in /usr/share users don't have write permissions to do so. This is wrong!!

Selected content (text/ and .txt files) is, in the other hand, supposed to be static. It's fine if we keep this in /usr, although to do so we need to change how the executable manages translations, and I don't have the knowledge to do so.

~/.simutrans(-extended) - user's own data - saves, screenshots, addons, paksets not available as packages, user modified configs

Problem is, simutrans doesn't look in that directory for paksets... and even if it did we would still have the problem of multiple users having to download the same package multiple times :-/

IMHO there is no need to use /var/games  (wargames ?)... Usually there are just highscore files shared with other users of the computer, but I don't see any use for that.

What was /var/games used for usually in the past should not tie us to do the same. The spec clearly says that any modifiable files should be there, it's up to us to define what the modifiable files are in Simutran's case.

An option would be to look into /usr/local/share/games/simutrans(-extended) for extra paksets, addons and such stuff, that is not packaged, but can be shared with other players. Also write access for non-admin users could be allowed for this directory.

This doesn't make sense. /usr shouldn't be writeable. We already have /var/games which fits well for our use case. Let's use it!

According to simmain.cc, the default data directory is /usr/share/games/simutrans-ex/ . Probably it is better, isn't it?

Phystam, this discussion is about changing the default data route directory (the name doesn't really matter), because currently users can't modify simutrans data.

P.D.: We may have deviated too much from the original thread. Should we open a new one to discuss this?

[Vladki]

    ~/.simutrans(-extended) - user's own data - saves, screenshots, addons, paksets not available as packages, user modified configs
Problem is, simutrans doesn't look in that directory for paksets... and even if it did we would still have the problem of multiple users having to download the same package multiple times :-/

That is the problem then. IIRC there is some optione "single-user-install" or such, that does exactly that.
My idea is that in /usr/share/... there would be default stuff from distribution, and each user would be allowed to override the deafults and add its own themes, paks, etc in ~/.simutrans
In my understanding /var is for files that change really often, i.e. with every run of the software. Yeah if there would be a headless server runnign as service, then /var would be a good place for server game saves.
But you do not download new themes and addons while playing. You do that at most as frequently as updating the base package. So putting SHARED paksets and themes to /usr/local/share/(games)/simutrans(-ex) is imho FHS compliant. E.g. in debian, there is a group "staff" that is allowed to modify stuff in /usr/local. In this case it could be even "users" or just everyone...

To put it simple, look for any type of files in this order:
~/.simutrans    (writable by user himself)
/usr/local/share/games/simutrans   (writable by "trusted" users)
/usr/share/games/simutrans  (writable by "admin" user)

The game itself should write only to ~/.simutrans

[Roboron]

That is the problem then. IIRC there is some optione "single-user-install" or such, that does exactly that.

I think you mean:

-singleuser         Save everything in program directory (portable version)

Which does exactly the opposite xD

My idea is that in /usr/share/... there would be default stuff from distribution, and each user would be allowed to override the deafults and add its own themes, paks, etc in ~/.simutrans

Okay, let's stick to this idea! I have been further discussing this issue outside of the community, to see how other games deal with this problem, and this seems to be the solution*. Let's forget about /var/games and /usr/loca/share/games. I was wrong identifying this as a package problem. This is a problem with the development of Simutrans. What we actually want is:

• Simutrans loading distribution's paksets and other data from /usr/share/games/simutrans and
• Simutrans loading user's paksets and other data from ~./simutrans in addition to the previous data

Currently Simutrans seems to be able to read data from other directories with the -use_workdir option. But that replaces the original base directory, and that's not exactly what we want. What we actually want is having a base data directory and a secondary data directory which can or can not have extra data to load. It is possible to do this (any developper reading this)?


* Additionally they expressed their concerns about having Simutrans' user directory in ~./simutrans. Instead, they told me, we should place Simutrans user data in ~./local/share/simutrans and Simutrans user config in ~./config/simutrans according to the XDG specifications.

P.D.: Now that I have determined that this is not a packaging problem, I'll keep uploading paksets to the Arch Linux User repository. Thanks for coming to my TED Talk.

[Freahk]

I think he meant the "singleuser_install" setting in simuconf.tab

To place paksets and stuff in any directory you prefer you may abuse the -use_workdir flag and set the working directory appropriately when launching simutrans.
However, I don't think that's a quite good idea as the autosave will also be stored there.

I guess the most linuxish solution is simply storing stuff in /usr/share and not allowing simple users to update their game.
To replace the binary you will need root access anyway.
If you really want to include user paksets from home you might mess with symlinks.

[prissi]

Almost all content in the simutrans data directory can be user modded using the local simutrans directory. There are very few settings, which cannot be modded (like the diagonal length modifier from a pakset). All user local addons will overlay the main addons.

The idea is that even after an update, you local modifications stay. Hence /usr/games/... should be static until updating. Modding the games can and should be done using ~/.simutrans or ./local/share

However, Simutrans has more than one config file, which also depends on the pakset chosen. So there cannot be a single config directory.

[Roboron]

Almost all content in the simutrans data directory can be user modded using the local simutrans directory.

How so? I've tried adding paksets to Simutrans using ~/.simutrans, but it doesn't seem like Simutrans looks for paksets there. Do you mean that the user can add things like themes and music to the base data using the local directory, but no paksets? Because that's the most important thing :/

If you really want to include user paksets from home you might mess with symlinks.

Actually a symlink seems like a wonderful idea, specially if there's no other way for the user to add paksets. Unfortunately, I've tried symlinking /usr/share/games/simutrans-extended/ to ~/.local/share/ and then compiling simutrans to read data from ~/.local/share/simutrans-extended, but it doesn't follow softlinks :-(

Code: [Select]

Use work dir ~/.local/share/simutrans-extended
Reading low level config data ...
FATAL ERROR: simmain() - No GUI themes found! Please re-install!
Aborting program execution ...
Maybe it works with hardlinks, but I don't think it's a good idea.

[Freahk]

What do you mean by "it doesn't follow softlinks"?
For paksets this works without any issues, I had a dual boot setup on my laptop for a long time and simply symlinked to the save and pakset dirs on the NTFS filesystem from my ext4 filesystem where I had places the Linux binaries.
If you want to symlink to the binary itself, you will neeed a small script rather than a symlink which passes the -use_workdir flag to the simutrans binary.

edit: hardlinks should indeed work as long as /home is on the same filesystem as /usr/share/. Otherwise it won't. That's how hardlinks work...

[Roboron]

What do you mean by "it doesn't follow softlinks"?

I was actually wrong. It does, if I start simutrans with the -use_workdir

Code: [Select]

simutrans-extended -use_workdir .
Use work dir /home/rober/.local/share/simutrans-extended/
Reading low level config data ...
Parsed simuconf.tab for directory layout; multiuser = 1
parse_simuconf() in program dir (config/simuconf.tab): Reading simuconf.tab successful!
SDL Driver: x11
Preparing display ...
Loading font 'font/prop.fnt'
font/prop.fnt successfully loaded as old format prop font!
Init done.
modal_dialogue( sel, magic_none, NULL, empty_objfilename );
And now it correctly detects paksets in /usr/share/games/simutrans and also paksets in /home/rober/.local/share/simutrans-extended/, exactly how I want to. So I just patched wrong the binary.

[Freahk]

I just had a look at how opensuse packages implemented it:

/usr/bin/simutrans

Code: [Select]

#!/bin/sh
cd /usr/share/simutrans
exec /usr/lib/simutrans/sim -use_workdir $@

They however don't allow for paksets and stuff in user dir.

[Roboron]

Code: [Select]

--- simmain.cc.orig 2020-02-06 17:10:51.716713070 +0100
+++ simmain.cc 2020-02-06 17:19:08.345736480 +0100
@@ -495,8 +495,9 @@
  strcat( env_t::program_dir, path_sep );
  }
  else {
- strcpy( env_t::program_dir, argv[0] );
- *(strrchr( env_t::program_dir, path_sep[0] )+1) = 0;
+        static char buffer[100];
+        sprintf(buffer, "%s/.local/share/simutrans-extended/", getenv("HOME"));
+        strcpy(env_t::program_dir, buffer);
I have now a working binary that defines the default data directory as ~/.local/share/simutrans(-extended)



pak48.Excentrique has been added by me in ~/.local/share/simutrans(-extended), while pak128.britain is installed system-wide in /usr/share/games/simutrans(-extended)  :-)

• Make Simutrans look for data in ~/.local/share/simutrans
• TODO Make Simutrans update the symlink each time it is opened
• TODO (Optional) Add an additional .txt file to explain the user how the symlinked  ~/.local/share/simutrans directory works

The second thing can be done with the command:

Code: [Select]

\cp -rs --remove-destination /usr/share/games/simutrans-extended/ ~/.local/share/
Which re-symlinks files everytime Simutrans is opened (to avoid paksets not being updated if you uninstall and the install a pakset again). This way we keep Simutrans updated everytime we install a pakset - and we also prevent the player accidentally deleting symlinked files and letting the game in an unplayable state.

[Roboron]

That's it, it is now done.



1. Make Simutrans look for data in ~/.local/share/simutrans
2. Make Simutrans update the symlink each time it is opened
3. (Optional) Add an additional .txt file to explain the user how the symlinked  ~/.local/share/simutrans directory works
4. (Optional?) Make Simutrans Extended symlink paksets in ~/.local/share/simutrans to ~/.local/share/simutrans-extended

So, while working on the symlink I thought that maybe it was a good idea to also make Simutrans Extended look for Standard paksets (some still work, I've noticed). So, right now, if I open Simutrans Extended i will get:

1. pak128.britain which is installed in /usr/share/games/simutrans-extended and symlinked to ~/.local/share/simutrans-extended by Simutrans Extended
2. pak64.excentrique which is in ~/.local/share/simutrans and symlinked to ~/.local/share/simutrans-extended by Simutrans Extended
3. 'pak' which is which is installed in /usr/share/games/simutrans and symlinked to ~/.local/share/simutrans by Simutrans Standard, and then symlinked to ~/.local/share/simutrans-extended by Simutrans Extended

¡Oof! I'm finally done with this. To inform the user about this I've also included a help file:

# Adding files in the user data directory (~/.local/share/simutrans-extended)

Files in this directory are symlinked from:

1. `/usr/share/games/simutrans-extended` (shared Simutrans Extended installation)
2. `/.local/share/simutrans` (paksets only, which is in turn symlinked to `/usr/share/games/simutrans` if Simutrans Standard is installed)

This means that the following paksets are already available here:

1. Paksets installed system-wide for Simutrans Extended.
2. Paksets installed system-wide for Simutrans Standard.
3. Paksets installed for Simutrans Standard by you in `/.local/share/simutrans`

If you already have Simutrans Standard installed you probably want to keep installing Simutrans Standard paksets in `~/.local/share/simutrans`, while installing Simutrans Extended paksets here in `~/.local/share/simutrans-extended`.

Adding paksets to these directories is the only way for non-root users to add paksets. You can also add non-pakset files (fonts, music, etc).

Symlinked files are updated everytime you open the game, so:

1. Don't worry about deleting symlinks by accident.
2. New paksets installed will be picked up automatically.

But please **don't replace symlinked files in this directory**. You will lose your replaced files when you open Simutrans! Instead, if you want, for example, to install another version of "pak64" rename it to "pak64-myversion".

# Adding files in the user config directory (~/.config/simutrans-extended)

Additionally, you can also add non-pakset files (fonts, music, etc) in `~/.config/simutrans-extended`

You can already install this patched version of simutrans-extended vía AUR: https://aur.archlinux.org/packages/simutrans-extended/.
Additionally, I've created a repository for the PKGBUILD of Simutrans Standard, so I can send it later to maintainers, if you like those changes: https://github.com/Roboron3042/simutrans-for-arch-linux.

[jamespetts]

Thank you very much for this, and apologies for not having replied nearer the time.

I should be grateful for any feedback on this from anyone who has tried this.

[Roboron]

I should be grateful for any feedback on this from anyone who has tried this.

So far the PKGBUILD has been working and auto-updating all this time, with the exception of a few days when the license location was changed and thus the installation was failing until I manually updated the PKGBUILD.

Oh, and some weeks ago it stopped compiling with the new release of GCC, but that was apparently later solved by yourself.

[jamespetts]

So far the PKGBUILD has been working and auto-updating all this time, with the exception of a few days when the license location was changed and thus the installation was failing until I manually updated the PKGBUILD.

Oh, and some weeks ago it stopped compiling with the new release of GCC, but that was apparently later solved by yourself.

Splendid, thank you for confirming, and thank you for your assistance with this.

[deMangler]

Just thought I'd mention - I tested this on Linux Mint 20 Kernel: 5.4.0-26-generic and it works great - I did need to install an appropriate libpng12-0_1.2.54 for my system. I think on some newer distros this version is not available in the standard repos.


Thanks for working to make this more available