Minetest: Making Minetest easy to install on all operating systems

Created on 21 Jan 2016  路  65Comments  路  Source: minetest/minetest

Discussions on IRC and forums have shown that Minetest is not that easy to install and integrate with the system, so I'm making this issue to keep track of problems related to ease of installation.

What needs to be done:

  • [ ] In portable Windows builds, put the minetest.exe binary at the root rather than in bin/
  • [ ] Provide official Windows installers (NSIS? InnoSetup? Squirrel?)

    • [ ] 64-bit

    • [ ] 32-bit

  • [ ] Provide official, distribution-independent GNU/Linux binaries (Static linking? .so bundling? AppImage?)

    • [ ] 64-bit

    • [ ] 32-bit

  • [ ] Provide official OS X .dmg or .pkg

    • [ ] 64-bit

@ Build Request / Suggestion

Most helpful comment

With flatpak being usable, it may be more interesting to go that route for Linux.

All 65 comments

For the portable Win32, I'd add a simple Play.bat (or Play.lnk [Windows shortcut file]) running bin\minetest.exe. I like that the binaries (executables and DLLs) are kept in their own directory, not cluttering the root.

I have made 64bit Windows build using Inno Setup. I'll make a 32bit one now.

For the portable Win32, I'd add a simple Play.bat (or Play.lnk [Windows shortcut file]) running binminetest.exe. I like that the binaries (executables and DLLs) are kept in their own directory, not cluttering the root.

Why not just minetest.bat then? At least, it doesn't lose all its meaning when you take it out of context.

Added a windows 32 bit installer to the releases. Updating website now...

Why not just minetest.bat then? At least, it doesn't lose all its meaning when you take it out of context.

Name does not matter, but it should be placed in the root. I chose "Play" as an example. Not sure what you mean by "context".

It you move it out of it's folder for some reason, maybe accidentally.

It can't be _too_ hard to change some settings to make minetest run from root of the minetest folder? No need for a .bat file. It also means minetest doesn't loss it's icon.

It works already when you run it from the root folder using ./bin/minetest.

It you move it out of it's folder for some reason, maybe accidentally.

Then how would it find minetest.exe?

It probably wouldn't. If it was accidentally moved then it wouldn't. I don't really know what Calinou meant.

Personally I'd prefer a shortcut over a bat.

How do you make a shortcut to a portable file? I don't think you can. I thought @Calinou meant running minetest.exe from root as in what freeminer does. Isn't this just a cmake setting?

Personally I'd prefer a shortcut over a bat.

It would be ideal, partly because it allows you to set an icon for it (though I'm not really sure if icons work with relative paths), and partly because it hides the file extension regardless of the "Show extension for know file types" setting.

I think shortcuts can be relative? I meant a shortcut in minetest root to the file in bin.

why not move the file?

why not move the file?

If you move minetest.exe, you must move all the DLLs, cluttering the root.

you could make it search for dlls in /bin, right?

you could make it search for dlls in /bin, right?

Yes, but you would need to alter PATH or similar, before running minetest.exe. So let's put minetest.exe in the root, along with, dunno, a batch file or a shortcut that modifies PATH, and then runs minetest.exe in the root. Sooo... why did we move minetest.exe to the root in the first place?

A batch file or shortcut does the job nicely: does not require patching the engine (if needed) to look in e.g. $exepath/games (currently it looks in $exepath/../games IIRC, which works from bin/), and keeps everything mostly tidy, only requiring a single extra file in the root. Am I missing something here?

Relative path shortcuts on windows are at best a hack, they can't have the minetest icon because they work by making command prompt start the program. .bat files can't have an icon either. If you don't want to make a few small changes to minetest engine then the best you can do will being more user friendly is to make another executable that will work as a launcher for minetest.

Relative path shortcuts on windows are at best a hack, they can't have the minetest icon because they work by making command prompt start the program

Windows does support both softlinks and hardlinks to my knowledge, at least since vista I think. They just don't have an UI in the explorer.

Just adding this: you can't attach a .bat shortcut in the task bar on Windows

[...]they can't have the minetest icon because they work by making command prompt start the program.

What do you mean by "command prompt", and what does it have to do with shortcuts? Did you mean .bat files?

[...]the best you can do will being more user friendly is to make another executable that will work as a launcher for minetest.

That could be a viable solution, even if the "launcher" just execvs bin/minetest.

@est31 Yep, Windows does support links as of Vista, but IIRC, from the point of view of the program loader, you still have the executable where the link is.

Maybe I'm misunderstanding @Calinou's point about this. I guess his point is that minetest.exe is "hidden" in bin. I'd add that it is also mixed among several DLLs that may confuse/overwhelm non-tech-savvy users.

Edit: Minor corrections.

Why not just use LNK files then?

@est31 I was wrong. Creating .lnk files with relative targets is not possible (at least from the GUI; it may or may not be possible programatically).

@est31 Good to know it can be done, but this line discards that option:

The icon is problematic, does not seem like it works with relative paths [...]

I agree with @red-001. A simple frontend/launcher .exe would be better.

The installer fixes most of these problems.

The installer fixes most of these problems.

Except the "no need for an installer" problem, which is, the _Whole. Fucking. Point._ of a portable package.

Why do I even bother anymore?

I agree with @red-001. A simple frontend/launcher .exe would be better.

A launcher typically means you must go through additional clicks. It does not improve the system integration of Minetest at all, eg. by providing system-wide shortcuts available in the Start Menu. (Currently, you can create one by hand and place it in %ProgramData%\Microsoft\Windows\Start Menu\Programs\Minetest).

@Calinou a launcher isn't neccessarily additional clicks, if it's just a simple .exe that launches it without any kind of GUI or anything. all it'd need to be is a quick wrapper program.

There's no need for that tone, @kaeza. Very rude.
If the point is to be noob friendly, then you should use an installers. Note that I said most of these problems.

A launcher typically means you must go through additional clicks. It does not improve the system integration of Minetest at all, eg. by providing system-wide shortcuts available in the Start Menu. (Currently, you can create one by hand and place it in %ProgramData%\Microsoft\Windows\Start Menu\Programs\Minetest).

Alll the installer does is unzip some files then make a shortcut. If you want system integration, that's how you do it.

http://www.portablelinuxgames.org/game/minetest

i can contact the maker... he can teach you, he helped me too

tux AT portablelinuxgames.org

Another option is just include ALL libraries into an folder called lib... and let the executable take them and not from the system...

See www.xonotic.org they have done it already, appimage seems to need more time

@lugarius Please edit your previous comments rather than posting several times.

Also @lugarius Appimage itself is discussed in #3568 in detail, so better to discuss about it there.

I also noticed this issue, and to combat this, I have started work on a launcher for the game, similar to MultiMC and the default Minecraft Launcher. You can find it here. It is very early in the works, only supports Linux, and compiles each new instance from source, which means that the system has to have the Irrlicht libraries and CMake installed, along with all of their dependencies.

Would this, if further developed, be a good solution to the problem at hand?

That's cool!

There might be a chicken-egg-problem for the use case of getting minetest releases work on all different distros, but it will be very useful for non technical users who want to try latest minetest from git.

It actually doesn't compile from master (though that's easy to add). It uses the GitHub tags to allow the user to download and compile any tagged version of Minetest. Unfortunately, it's limited to compiling, as Minetest doesn't actually provide releases for Linux (though that's kind of what this entire issue is about).

FYI I can compile Minetest in < 5 minutes, so I'd be happy to compile and cross compile stuff.

Any succsess in Appimage??

Any succsess in Appimage??

I have tried making a quick-and-dirty AppImage of the latest Minetest Git on a Ubuntu 12.04 64-bit chroot, but it does not work outside of the chroot (on Arch Linux, for example), I believe it needs some tweaking. It also doesn't provide LevelDB support due to a bug in Ubuntu 12.04.

With flatpak being usable, it may be more interesting to go that route for Linux.

Try Ubuntu 14.xx LTS..

I've created a flatpak build script for the minetest client: https://github.com/est31/minetest-flatpak

Maybe we can even make an official repo for flatpak for release + nightly, but someone would need to supply a buildserver for this (hosting can happen on github pages).

@Calinou
https://forum.minetest.net/viewtopic.php?f=42&t=15802

I am for AppImage, add them to the download page?

any news?

Do the checkboxes need updating? Any more thoughts?

Here is an installer package for Minetest 0.4.16. I can create more for later versions if necessary. https://github.com/lucasburlingham/Minetest-0.4.17.1-Client/raw/macosx/minetest-0.16.0-client-macosx.pkg

Is there core dev support for the remaining checkboxes? Or should this be closed?

Now that we have Windows installers and a Minetest Flatpak, I think only macOS support remains an issue. However, we don't have any dedicated maintainer for it :slightly_frowning_face:

So, feel free to close this issue.

Edit: It seems we no longer have Windows installers on the Download page, we should restore them eventually.

We don't have Windows installers - having the capability doesn't count if they're not created

@rubenwardy I just checked the website and can't see them on the Download page indeed. I remember them being present on that page at some point.

I have a Windows boot. I'm willing to create Windows installers for each release (Or figuring out a Github-run script).
My main OS is Linux, so I can look into creating AppImages too if @benrob0329 doesn't want to do that

Hmmm, it looks like we already have the ability to make installers? Why aren't we using it?

still no portable linux download (.tar.gz, .appimage)??

still no portable linux download (.tar.gz, .appimage)??

Please, do this, I beg.

@Tcll @themagicalcats Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

Also, I believe the Flatpak is a good enough solution to installing Minetest on any Linux distribution nowadays.

I believe the Flatpak is a good enough solution to installing Minetest on any Linux distribution nowadays.

flatpak requires internet to use apps and is not portable
the PC I can play minetest on is offline

this is why I suggested an appimage or pre-built tar.gz I can transfer to that machine
all I'll have to do is extract and run (appimage doesn't need to be extracted, but I do so anyways for dev reasons)

it's up to the devs to build binaries for users, not users to build binaries for themselves

I should also note I'm against system installations for portable apps, which is why I don't just download the xbps package
I prefer my portable apps on my secondary HDD for use with multiple linux distros

Only stumbled on this by accident, so I鈥檒l just briefly pipe in:

flatpak requires internet to use apps

This isn鈥檛 true. The whole infrastructure for offline distribution is in place and has been actively used for years. See the docs for simple instructions.

If you need portability (aka you want it to be able to be run from a USB), then also provide an AppImage. Although I鈥檇 argue that鈥檚 a separate use-case.

The whole infrastructure for offline distribution is in place and has been actively used for years.

alright thanks, I had some bad experiences in the past, particularly with SparkleShare, but there were a few others as well...

I鈥檇 argue that鈥檚 a separate use-case.

portability is the primary reason appimage exists, it's anything BUT a separate use case ;)

but I'm suggesting tar.gz as well like Blender does in case appimage is too much of a hassle to build properly
just build the app and throw it in a tar.gz for the same reason you'd build an appimage
(the problem with this though is the very reason Blender 2.8 runs at 0.5 FPS as one of my system libs are bad)
^ appimage would bundle everything assuring issues like this wouldn't happen if built properly

I had some success building a Minetest appimage some time ago, but was waiting on a few tooling changes to make it easier on older distros (namely pulling in the appdata/appinfo/what'cha'ma'call'it parser from an appimage so-as no to rely on the outdated one in the repos).

Those changes may be done now, though.

just wanted to update, with help from a friend, I've found these which seem to work quite well :)
https://github.com/An0n3m0us/Minetest-AppImages/releases
for an added advantage, I don't even have to extract to add a missing lib, it just works as is :D

it's a shame these aren't official though u.u

@Tcll I meant portability is a separate use-case to offline installation. I still think Flatpak is better for an offline computer because then you鈥檇 probably have more apps installed and it makes it easier to keep them updated and it uses disk space better. But an AppImage is vastly superior to carrying it around on say a USB stick.

I meant portability is a separate use-case to offline installation.

oh I see, portability vs offline installation, I suppose I can agree with that >.>

though I still disagree updates are easier to manage through an automated interface
if anything, it's more a hassle when you want to manage multiple versions of the same app
eg: I still have a need for collada importers on Blender 2.49 because the 2.79b importers are broken (and 2.8x runs at 0.5 FPS).

and don't even get me started on multiple linux installations on the same HDD ;)
[[swap][boot][[OS1][OS2][OS3][...][data]][recovery]]
where my programs are stored in the data partition (if not another HDD)
at least XFCE makes panel-launchers easy

Was this page helpful?
0 / 5 - 0 ratings

Related issues

KenneyNL picture KenneyNL  路  66Comments

tacotexmex picture tacotexmex  路  83Comments

adamryczkowski picture adamryczkowski  路  53Comments

Wuzzy2 picture Wuzzy2  路  76Comments

est31 picture est31  路  51Comments