- Welcome to The International Simutrans Forum.
News:
Simutrans Forum Archive
A complete record of the old Simutrans Forum.
A complete record of the old Simutrans Forum.
Posted by deMangler
- November 15, 2020, 11:39:49 AMJust 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
Thanks for working to make this more available
Posted by jamespetts
- June 08, 2020, 04:42:14 PMQuote from: Roboron on June 08, 2020, 03:46:04 PM
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.
Posted by Roboron
- June 08, 2020, 03:46:04 PMQuote from: jamespetts on June 08, 2020, 03:26:28 PMI 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.
Posted by jamespetts
- June 08, 2020, 03:26:28 PMThank 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.
I should be grateful for any feedback on this from anyone who has tried this.
Posted by Roboron
- February 06, 2020, 07:54:27 PMThat'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:
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.
1.
Make Simutrans look for data in ~/.local/share/simutrans2.
Make Simutrans update the symlink each time it is opened3.
(Optional) Add an additional .txt file to explain the user how the symlinked ~/.local/share/simutrans directory works4.
(Optional?) Make Simutrans Extended symlink paksets in ~/.local/share/simutrans to ~/.local/share/simutrans-extendedSo, 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:
Quote# 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.
Posted by Roboron
- February 06, 2020, 05:15:49 PMCode 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
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.
Posted by Sirius
- February 06, 2020, 03:36:07 PMI just had a look at how opensuse packages implemented it:
/usr/bin/simutrans
They however don't allow for paksets and stuff in user dir.
/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.
Posted by Roboron
- February 06, 2020, 02:29:39 PMQuote from: Freahk on February 06, 2020, 01:20:44 PM
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.
Posted by Sirius
- February 06, 2020, 01:20:44 PMWhat 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...
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...
Posted by Roboron
- February 06, 2020, 01:12:49 PMQuote from: prissi on February 06, 2020, 02:32:23 AM
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 :/
Quote from: Freahk on February 05, 2020, 10:36:02 PMIf 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.
Posted by prissi
- February 06, 2020, 02:32:23 AMAlmost 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.
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.
Posted by Sirius
- February 05, 2020, 10:36:02 PMI 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.
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.
Posted by Roboron
- February 05, 2020, 08:09:54 PMQuote from: Vladki on February 05, 2020, 01:30:01 PM
That is the problem then. IIRC there is some optione "single-user-install" or such, that does exactly that.
I think you mean:
Quote-singleuser Save everything in program directory (portable version)
Which does exactly the opposite xD
Quote from: Vladki on February 05, 2020, 01:30:01 PMMy 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.
Posted by Vladki
- February 05, 2020, 01:30:01 PMQuote from: Roboron on February 05, 2020, 12:59:42 PM~/.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
Posted by Roboron
- February 05, 2020, 12:59:42 PMQuote from: Vladki on February 05, 2020, 10:39:43 AM/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 :-)
Quote from: Vladki on February 05, 2020, 10:39:43 AM/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:
QuoteThe /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.
Quote from: Vladki on February 05, 2020, 10:39:43 AM~/.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 :-/
Quote from: Vladki on February 05, 2020, 10:39:43 AMIMHO 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.
Quote from: Vladki on February 05, 2020, 10:39:43 AMAn 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!
Quote from: Phystam on February 05, 2020, 11:16:25 AMAccording 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?
Posted by Vladki
- February 05, 2020, 12:36:54 PM-ex or -extended, whatewer...
Posted by Phystam
- February 05, 2020, 11:16:25 AMAccording to simmain.cc, the default data directory is /usr/share/games/simutrans-ex/ . Probably it is better, isn't it?
Posted by Vladki
- February 05, 2020, 10:39:43 AMQuote from: Roboron on February 04, 2020, 07:23:43 PMJames, 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.
Posted by Phystam
- February 05, 2020, 09:15:18 AM Thank you;) (however, I'm not an Arch Linux user...
Posted by Roboron
- February 04, 2020, 08:31:09 PMQuote from: Phystam on February 04, 2020, 07:33:56 PM
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.
Posted by Phystam
- February 04, 2020, 07:33:56 PMHow about pak128.sweden-ex and pak256-ex? Probably they could be available.
Posted by Roboron
- February 04, 2020, 07:23:43 PMQuote from: Matthew on February 04, 2020, 04:29:53 PM
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!
Quote from: Matthew on February 04, 2020, 04:29:53 PMThe 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.
Quote from: Matthew on February 04, 2020, 04:29:53 PMThe 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).
Quote from: Matthew on February 04, 2020, 04:29:53 PMI 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:
Quote
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...
Quote from: Matthew on February 04, 2020, 04:29:53 PMOh, 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
Quote from: Vladki on February 04, 2020, 04:48:33 PM
James, i disagree with you.
You mean Matthew right?
Posted by Vladki
- February 04, 2020, 04:48:33 PMJames, 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.
Posted by Matthew
- February 04, 2020, 04:29:53 PMQuote from: Roboron on February 04, 2020, 05:01:06 AM
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.
QuoteI'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: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.
- 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.
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.
QuoteP.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.
Posted by Roboron
- February 04, 2020, 05:01:06 AMI'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:
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).
- 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.
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).