Install method for Linux

[qreeves]

Currently, we have a few inexperienced Linux users (mainly Ubuntu) who have been tripped up by the fact that online support has ended for the version distributed by their respective distributions. These users typically don't know how to use the command line, and some are even confused why our packages don't replace the shortcuts from the ones provided by their distribution.

What we could use is an install.sh or something similar, which can set up a $HOME hosted install with shortcuts the user can use. This would be separate from the makefile as this is an install method done from the package we distribute.

[Jigoku]

As for shortcuts and menu items. You'd want to generate a desktop file named red-eclipse.desktop which would be linked to ~/.local/share/applications and ~/Desktop.

Something like this would make shortcuts:

#!/bin/sh
cat <<EOF > red-eclipse.desktop
[Desktop Entry]
Name=Red Eclipse
Comment=Aurora Edition (1.5)
Exec=${PWD}/redeclipse.sh
Icon=${PWD}/data/textures/emblem.png
Path=${PWD}
StartupNotify=true
Type=Application
EOF

chmod +x ${PWD}/red-eclipse.desktop
ln -s ${PWD}/red-eclipse.desktop ~/.local/share/applications/red-eclipse.desktop
ln -s ${PWD}/red-eclipse.desktop ~/Desktop/red-eclipse.desktop

If you run this script from within the location you extracted the red eclipse tarball (ie; install.sh), it makes the local install launchable via the menus/desktop search tools, and also as a desktop icon.

If the user were to delete the local install, the shortcuts also disappear due to being symlinks.

[alchzh]

and symlink redeclipse.sh into /usr/bin? maybe?

ln -s ./redeclipse.sh /usr/bin/redeclipse.sh

[Jigoku]

I noticed a pre-existing redeclipse.desktop.am that includes translations in the src/ directory, using that as a base, the script in the pull request creates a new *.desktop file while adjusting the Icon/Exec paths for the local folder install.

You would only need extract the tarball somewhere, (possibly ~/bin most people would use) then double click install_nix.sh and the game can then be launched from menu shortcuts for that user.

@acz13 could do that, but /usr/bin (or even /usr/local/bin) would require root access

[ienorand]

I've done a quick test with one method to do it in ienorand/base@57862f1 where it's just installing a desktop file which links back to the unpacked tarball.

I don't feel like there's any particularly good solution to this issue to be found...

[TheLastProject]

What is wrong with .deb and so packages? Those cause a pretty user-friendly installer screen when opened (screenshot on KDE as example):

EDIT: When using the package name redeclipse as well, I am pretty sure it would overwrite the current installed version.

[qreeves]

@TheLastProject The built-in updater can create "untracked" files, which would fail to be removed when you used dpkg --remove. You would have to create inplace packages.

[ghost]

You can always use an out-of-system package management solution like icculus's MojoSetup. Doesn't integrate into package management, but gets the job done easily. Besides, RE effectively deprecates the need for real package management in 99% of cases due to the built-in updater.

[ienorand]

@TheLastProject With distro packages we need a good way to build and distribute them, thus far that has been using the distros infrastructure themselves, but in case there's now going to be a much faster release deprecation, the inherent lag in that might become too big of an issue (I'm still hoping it won't).

...

Since PlayDeb seems to still be fairly active, I'm thinking that with them complementing distros, it might be alright (Fedora et. al. will suffer I guess, but that's more due to prioritizing).

For distro-packages to work with auto-downloading, everything would need to be kept in the homedir, including new binaries... But think I'd prefer to leave distro packages to do versioning statically and as intended by their distros.

I did the test-implementation above based on using the unpacked tarball in-place. I'm not sure if it would instead be desirable to do a mostly complete copy for user-installation?

It's not replacing the command-line stuff either (although that can in many cases be done by adding ~/bin/redeclipse and ~/bin/redeclipse-server depending on if the shell is setup to add and prioritize ~/bin in $PATH). Manpages does not seem possible to override though, since manpath by default isn't set to include a user-location, not sure that's particularly important though, given the stated audience.

[alugarius]

Actually ubuntu 16.04 comes with sdl installed Including emergency libs to run the game would be nice. Another option would be an appimage, but updates would be hard then...

[probonopd]

AppImage has a binary delta update system, so why would updates be hard? https://github.com/probonopd/AppImageKit/tree/master/AppImageUpdate.AppDir

[qreeves]

This topic isn't about updaters, etc. It is about an install method for Linux that works from our package.

[alugarius]

Well... on ubuntu is no installation needed, Download, run and fun! Appimage is an good idea I think.

Otherwise: We should do something like Xonotic, one zip file for Linux windows and Mac, including needed library's and done.

Ps: we have to include an .desktop file because scipts.sh are not easy to run! They have to be drag and dropped into the teminal!

[TheAssassin]

How about setting up a PPA for Debian and Ubuntu? I have lots of experience with Debian packaging and PPA maintenance and could contribute that. We could even automate the packaging process to provide users with nightly builds etc. created as part of the continuous deployment processes on semaphore or on my own CI infrastructure. And I could use the existing packages as a base so that old distribution packages are upgraded correctly. Apart from that I should be able to find a maintainer (or at least initial creator, maintenance isn't that hard) for RPM packages.

I agree on the inclusion of a desktop file, I wrote one for my own needs a while ago (which is going to be extended to support redeclipse:// protocol soon) which could be included either in the community repository or later distribution packages (no need for generation using Makefiles etc. then because the paths won't change).

@alugarius: I don't know what distribution you run, but on my Xubuntu I can just double click the shell script if it's marked as executable. This should actually work with all desktop environments.

Btw: It's always worth building packages etc., because it's not necessarily "download, run and fun". There's dependencies that have to be installed and other similar problems that the end user is confrontend with, and ideally they can just install it and then run it from their "start menu".

Btw: A Docker image for the client could solve all these problems, too. :)

[alugarius]

The way how it is right now is ok! Adding an .desktop file to the start script would be nice!

[alugarius]

RE 1.5.5 comes now with SDL2, now its not working out of the box anymore, i suggest shipping Red Eclipse with SDL2 and other needed libs! An desktop file that starts the updater and the game and its done!

I wonder how Xonotic is doing that...

[alugarius]

I made an SDL2 installer that uses the sourcecode itself, it should work on any unix and is started with an simple script..... How does that sounds?

[TheAssassin]

Doesn't your OS provide packages for SDL2 and the mixer and image libs? Every major distribution has them now... The only one I know that does not (yet) ship SDL2_image and SDL2_mixer is Alpine Linux, which is why I compile the libs there manually. https://github.com/TheAssassin/redeclipse-docker/blob/master/Dockerfile#L10

[alugarius]

Its for all thay dont have a proper pakage manager or no internet!

[alugarius]

Not everyone has internet... but this people should able to play too!

[TheAssassin]

Even if it's really unlike (playing Red Eclipse offline?), I agree there is that use case. But saying "its not working out of the box anymore" is not really a correct or precise statement. There was a dependency on SDL version 1.2 (and the image and mixer libraries), and now these dependencies were upgraded to version 2. You basically assume that 1.2 has been installed on every system before, which is really as unlike as people who would want play the game without an internet connection. People who actually have that problem will usually find a solution how to get SDL 2 packages, too (since they had to get the RE binaries from some other computer, too), or compile them from source. I think it'll be more useful if you create a wiki article that explains how to get any dependency from source or how to download the according distribution packages. This is less work to maintain because it is not in the code that everyone will have execute, thus nothing will be broken if there's changes in the dependency list.

[alugarius]

its the offical source with an autocompiler, it solves the problem that some people have, i created it for warsow

[graphitemaster]

If you moved to using zip archives and mountzip in the engine, the ingame updater can then just download a zip and the engine can use rename (which is atomic) to rename the new zip over the old one. Distro package managers not only track files but also their hashes which means a "reinstall" of redeclipse would still trigger and have it replace the newer zips with poentially older ones. However your package manager's removal will work correctly.

[qreeves]

This entire conversation is off the issue topic.

[TheAssassin]

FYI: There is a project for Red Eclipse AppImages now: https://github.com/TheAssassin/redeclipse-appimage Thus, we could upload AppImages to the base repository for new releases.

[qreeves]

AppImages are now officially available at: http://redeclipse.net/download