Terasology Packaging (Linux distros, Windows, Mac) - Discussion

qwc

Docker Dude!
Contributor
Small update:
I got the permission from FSMaxB (AUR username) for the arch linux package to use his sources.
see: Existing Archlinux Packages

I'm currently planning the packaging build chain and after the answer from the debian package maintainer I'll start setting the parts up, lets see when we have something working. :geek:
 

qwc

Docker Dude!
Contributor
Next small update, got the permission from ckorn (github username) to use his sources for package generation from his playdeb/getdeb project. :thumbsup:

So now I can fully concentrate on setting the packaging chain up. :ninja:

Still I would welcome some comments/critics on my ideas for package variants and/or targeted distributions, you can just approve of course. :D
I would also welcome some ideas for preconfigured server configs apart from the current standard for the docker image, for easier/faster setup. :coffee:

AUTOMATE ALL THE THINGS! :geek:
 

gianluca_n

New Member
Contributor
I made a first stub of an NSIS-based launcher installer for Windows, here is the commit.

I tested the build process both on Windows and on Ubuntu 16.04 and it works fine on both, provided makensis is installed.
I saw now that your Arch package directly installs the game, while my Windows package installs the launcher.
I went this way since I thought this could make easier delivering updates, the user installs the launcher (operation which requires admin privileges) once and then within the launcher he/she can set the version to play without requiring privileges.
Obviously if you think this is not the right way, any idea/suggestion is welcome.

I'm not opening the pull request now since I think there are things that should be improved; for example, whether the installer should automatically set the game and data directories (for example to subdirectories of the user's %appdata%) (it actually doesn't).
Also, the installer now currently bundles the core launcher files only and weighs ~5MB. I saw in the Launcher issues that there are plans to bundle the JRE; I'm not sure if the installer should do so. Personally, I don't like when programs bundle the JRE since I already have a system-wide install of it that I keep up to date and thus I think it simply "pollutes" my machine. It is possible to detect the JRE from the NSIS installer and instruct the user to install it if it's not found; also, if we publish the installer to Chocolatey it is possible to add it as a dependency. However this is just my personal opinion and, considering I'm also quite new to this community, by no means I want to go against ideas other people have developed and carefully thought about; if you prefer me to build an installer that bundles the JRE, I'll do it.
 

gianluca_n

New Member
Contributor
If anyone is interested: I improved the NSIS installer, implementing JRE detection.

Link to full diff from launcher's develop branch

It does not allow to install if a JRE or JDK installation with Java 8 support (minimum version, together with some other values, can be changed from the Gradle file, which builds the installer) can't be found.
If a only a 32-bit Java installation is found on a 64-bit system (i.e. a WOW64 Java installation), the installer warns the user advising to download a native 64-bit JRE to get better performance.

I made various test both on my machine and on a freshly installed Win10 VM alternating different Java installations, here are some screenshots (imgur album).

The installer is built by the launcher's Gradle project; should work on Jenkins provided makensis is installed (it works on Linux too).
Still needs some more metadata to show in Add/Remove Programs (i.e. link to website), an icon and maybe a replacement for the default image on the welcome page (the blue rectangle in this image).

Again, looking for feedback, especially from fellow Windows users and people working on the launcher (but anyone, really). IMHO this could be a nice way to deploy to Windows, since will suit both users used to the classic installation wizards (when ran normally) and could be wrapped in a Chocolatey package with dependency on JRE for power-users (the choco script will run the installer with the /S command line switch that installs without requiring user interaction).
 
Last edited:
Reactions: qwc

qwc

Docker Dude!
Contributor
Wow, thanks for keeping up with the windows installer.

Due to private reasons I just began providing basic things for the packaging, As soon as I'm ready to include your installer script I'll contact you, if there are questions. :)
 

Skaldarnar

Development Lead
Contributor
Art
World
SpecOps
@gianluca_n Nice work with the launcher installer script. Please open a PR, if you think its not ready for merging yet just prepend a "[WIP]" tag. Bundling the JRE was an idea to avoid issues where users did not have Java installed, had some very old version, or running a 32bit Java on 64bit Windows (and, for the launcher, there was/is also a problem with JavaFX and OpenJDK). Bundling it would give us the control over the version used, but increases the download size (and it might also be a security risk for some when we don't update the Java version frequently). @shartte got the JRE bundling set up for the launcher, I think there is still a build job in Jenkins. I was hesitant to merge this because it blows up the file size of the download, that's why I started looking into delta updates (incremental updates only for changed parts). Your install script seems to make this superfluous, and with packager managers we can specify dependencies even better.
 

qwc

Docker Dude!
Contributor
I've changed the permissions on my jenkins instance so that everyone can view jobs and download artifacts.

The packaging view can be found here: https://jenkins.mmo.to/view/Packaging/

Still bare playground area. Debian package can already be downloaded, currently only installs binaries to /opt and does not create any links or desktop files. So to start the game with this package installed you have to go to the folder and run the game all manually.

Current agenda for linux packaging:
  1. [done] provide binary packages (deb, rpm) using fpm, just the game which is installed.
    • Launcher not available as rpm due to missing dependency at least @fedora, may be resolved later on.
  2. [done] integrate convenience scripts/links
    • link from /usr/bin/terasology to the start script
    • provide a terasology.desktop file for DEs to parse and integrate into the starter programs (KDE, Unity, Gnome, etc.)
  3. [done] setup small own signed debian repository, for continuous delivery for debian
    • Inform debian/ubuntu maintainer of this repo, so that he can update his packages from there
    • [done] implement package signing
  4. [ ] Extend packaging to archlinux [binary/AUR] and gentoo
    • On completion inform archlinux AUR maintainer to swich package source to generated one.
  5. [ ] build SNAP and flatpak packages
  6. [ ] Add packages page to terasology website for downloading/configuration of package sources.
Working on these tasks as I have time, so be patient. :geek:
 
Last edited:

gianluca_n

New Member
Contributor
@qwc kudos to you, managing all that packaging methods sounds like a lot of work!

I tried the .debs on my Ubuntu 16.04; the launcher package works fine, while I couldn't start the game from the standalone package with the script that is installed at /usr/bin/terasology. Seems like it doesn't cd to the right directory since it says it can't find the jarfile. Going to open an issue on your repository.

Some updates from the Windows world: the installer is nearly finished; current features include:
  • JRE/JDK detection, with critical error message (will halt the installation) with instructions to download the latest official JRE if no proper Java installation is found, and warning if only 32-bit Java is found on a 64-bit system.
  • Localization - the installer pages are fully localizable; lots of strings, the generic ones for any installer, are already provided for many languages by the NSIS project, while the custom strings (like the "missing JRE" messages) are stored in .properties files and put in the installer script by the Gradle pipeline. I opted for the .properties format so that we could add this as a new component for the launcher project on Weblate to simplify the work of translators.
  • Cleanup - the PR includes changes to the launcher code to allow the user to choose which directories should be deleted on uninstallation (launcher config directory, game assets directory and data directory). Basically, starting the launcher with the "--cleanup" command line argument opens a dialog that asks the user to choose what to delete; this could be useful for other types of packages too, however something like a "--silent-cleanup" variant probably needs to be set up so that it can delete a default set of files (maybe only the game assets directory which is the biggest one and contains things that can easily be redownloaded) without showing the GUI.
What I still want to do before removing the [WIP] tag from the PR is working on the auto-update. Right now if a launcher update is found the launcher will try to replace itself with the new version, however this wouldn't work when it is installed to a system-wide directory which a normal user hasn't permission to write to (like C:\Program Files\TerasologyLauncher which is the default); I think - correct me if I'm wrong - this is a problem on Linux too unless you grant any non-superuser the write privilege on /opt.

I'm going to refactor the update system to support multiple updating methods; when a new version is found, the launcher will select the most appropriate update strategy according to, for example, a file which the installer/package has put in its directory. So, the default update strategy, used when the installer is simply extracted from the ZIP produced by the Gradle build (supposedly to a user-writable location), would be the current auto-updater; if the launcher was installed by the NSIS Windows installer, it could download the new installer and run it (the installer requires administrator privileges, so when it's started Windows shows the UAC dialog to elevate the user, possibly asking for a password); if it was installed by Apt/Pacman/Chocolatey/etc it could be a simple message dialog asking "please run the following command (e.g. apt-get upgrade terasologylauncher) with superuser privileges to get the latest version".
 
Reactions: qwc

qwc

Docker Dude!
Contributor
@gianluca_n Thanks, well it really is a bunch of work, but as I am working directly towards automatisation I will have that work only once. :cool:
After that just maintainance is needed. I like those tasks, they give me the possibility to dive into different distributions again. I'm an ArchLinux user and ever will be one, but it's always good to look over the edge and to know what has changed at other distributions. :geek:
Installation of packages on Linux distributions always needs super user rights, so that won't be a problem. Those who want to install the game as a user, well there's still the ZIP. :p

Nice work at the Windows front! :gooey: Currently can't think of anything to add. :D
 

qwc

Docker Dude!
Contributor
Debian/ubuntu repository is up and running: http://terasology.mmo.to/deb/
Feel free to test a bit, also added a fix for starting the game with the script in /usr/bin/.

I've got enough for today, gonna relax this evening. :D
 

qwc

Docker Dude!
Contributor
Thanks, will correct that.
 
Top