Mac, Windows, and GNU/Linux packaging #110
Comments
It's actually quite different to Windows. There are two ways to install things on OS X. The first is through .app packages: if you make a directory named foobar.app with its contents structured in the correct way, it appears as an executable app in the Finder. See here for example (Chocolate Doom is actually Chocolate Doom.app): http://www.chocolate-doom.org/wiki/images/c/c6/OS_X_DMG.png Installing one of these apps is simply a matter of dragging and dropping it into the Applications folder. This sets up file associations etc. automatically. Uninstalling is just a matter of dragging to the trashcan. These are normally distributed as .dmg (Mac disk image) files. The .dmg usually contains the .app folder and a symlink to /Applications that the user can drag it to. The other way of installing on OS X is through .pkg files. These are binary files that the Mac Installer program processes and installs. Usually .pkg files are for packages that make system-level changes (like device drivers for example). They're for things that don't really fit the normal mold of "app that you can run". I think that .app is strongly preferable to .pkg for Freedoom. The one disadvantage is that you can't modify the PATH with .app but I don't think it's a big deal. Command line users can update their PATH themselves if they want. For Chocolate Doom I came up with a clever solution where the launcher program has a menu item that will open a new Terminal window with PATH and DOOMWADPATH set appropriately and we could do the same thing for Freedoom.
I agree that we should do this. I don't have a strong preference about which port, except that it should obviously be free software licensed and Boom compatible. It also makes sense to use the same port across platforms and not different ports on Windows and Mac. Odamex fits this well I think. PrBoom[+] is also an option but the convoluted menu systems make it kind of a turn-off. |
|
When talking to a friend about Freedoom and I mentioned it has a "make install", he seemed glad for that but also confused about the difference between game engine and assets, and persistently kept asking why the 'script' couldn't install both at the same time. While his specific solution is not very valid for us, it does probably highlight a need to make our own packaging for all three major OSes (GNU/Linux, Mac OS, Windows). He primarily uses CentOS 6 and 7 desktops, preferring that distro for its very long-term support cycle, and it lacks any Doom engines and Freedoom from the main repositories. I don't think his situation is particularly unusual, and it would help to gain a universal GNU/Linux package to install, as well. I think we can get away with building engine binaries for some "lowest common denominator" (likely CentOS 6?) that will work for most desktops as-is. (I'm placing this thought out here, but we cannot focus on packaging until after the 0.9 release. I'll edit the first post though.) |
chungy
changed the title
|
One thing I've learned about packaging is that what makes sense for one platform doesn't make any sense for others. Things are done differently in the Linux world and there's a lot more focus on distro package repositories. Freedoom is already in most of the major distros - Debian, Fedora, etc. I'm not convinced that there's the same need to provide a pre-packaged installer for Linux that there is for Windows or Mac. I think the CentOS case is an unusual one - it's an Enterprise distro that's basically not designed for gaming. I'd be more tempted to recommend installing the Freedoom and Prboom packages from the equivalent version of Fedora that the CentOS release was based on, rather than going to the trouble of making a Linux installer. It's also worth pointing out, but "universal Linux package" is really hard to do well. I don't know if you've ever tried making such a package in the past. Basically it's a lot of work for dubious gain when Freedoom is already part of most distros already. If there are prominent distros where it isn't available, I'd much rather expend the effort convincing them to make packages for Freedoom (or doing it for them) than trying to make a "universal" Linux package. |
|
Mac .app's are weird. Despite being closer in codebase to Mac, I always thought Linux was closer to windows in how it handles files. As for a universal launcher...python or java? |
|
Mac is pretty different from both Linux and Windows (and shares no code with Linux either, fwiw), you have to treat all of them independently. @fragglet has a point about universal Linux packages being really hard to do well. I think such a thing is on the lowest priority here after Mac and Windows, but I still believe it will be good to have eventually. I'm not putting a lot of thought into it yet... not until 0.9 is out anyway. |
|
I said closer. Linux and Mac have a common ancestor in UNIX. |
|
It's great to see these discussions taking place (and moving to github and using their issues is, IMHO, a great idea. In fact it's pretty inspiring; perhaps I'll contribute a patch or two again :)) Anyway, I love the idea of having a 'blessed' port, and a bundled thing to make playing easier. It reminds me of the GNOME project's "GNOME OS" thing to some extent. I think also a half-decent launcher is a good idea. It doesn't even have to be a freedoom-specific project; I think the world is crying out for a modern launcher for Doom full stop. FWIW at the moment I am a Mac user so I might have a go at road-testing any attempts to do a .app set up for Freedoom or a Freedoom bundle. |
|
I made a base bundle that should be slightly easier to use than the default Odamex install, for Windows, and I think the server files included may be useful for other operating systems. To make the server, all the player has to do is start odasrv, the server will start under cooperative settings, and the server console will echo some aliases to change the current gamemode/wad. Quoting from the files we have: echo "Game modes available:" Well, it is the best my skills can do at the moment. The current folder hierarchy is the following ./bin Compressed - https://mega.co.nz/#!kJBAgYTD!NDP6PTCHnoEX38RMYi1Vje6WB3lV7z1JFPaWsHAVHb0 Installer (Inno setup) - https://mega.co.nz/#!NRQliIJB!5COiDrA13wzm7hpNRRfYhmKgehKDRsFX3euijoOqw8A Inno Setup script goes below, because I don't know how to use git yet.[Setup] [Files] [Icons] |
|
I've packaged Freedoom for Linux with GZdoom as Flatpaks: https://github.com/flathub/io.github.Freedoom-Phase-1 If a Freedoom maintainer would like to have push access, he can contact one of the Flathub admins: https://github.com/orgs/flathub/people |
The work done for issue #100 means that we have a stable interface for installing Freedoom on traditional Unix platforms (such as GNU/Linux, *BSD, illumos, etc) as if it were a regular application. Manual installs still mean that users need to seek out an engine independently, but installs through a package manager should hopefully pull in one as a dependency. [1]
Two large segments of users are still left out from ease-of-use: Apple Mac OS X and Microsoft Windows. I personally am not familiar with Mac so I don't know the issues specific to it, but I suspect it is similar to Windows: lack of centralized package management and engines not being installed in standard locations on the $PATH.
Most engines made for Windows still treat installation and execution exactly as if it was DOS: users are expected to manually unpack an archive with the executables in one location, drop IWADs within that location, and manually set up any shortcuts on their own. There are no real standard locations and I doubt the majority of users will, nor know how, to set up their %PATH% to point to their engines. Additionally, most/all engines do not save configuration in the %APPDATA% directory, which may prove problematic for installed versions of these programs.
I believe the best action moving forward will be to make platform-specific packages that bundle an engine with Freedoom and automatically set up start menu icons/desktop icons/etc and make the game a breeze to play. I think Odamex is probably one of the better choices of ports to include. We should be able to work with Odamex upstream on getting this goal set, and making an installer (I've worked with NSIS, for Windows, in the past, it's not too difficult).
[1] UPDATED: While it is good to work with distributions to get Freedoom packaged and easy-to-run from software repositories, there will always be large distributions that lack Freedoom and Doom engines entirely (such as Red Hat Enterprise Linux/CentOS) or distributions that lag behind releases and some players may want to install their own copy which is fully up-to-date. We should also have a generic stand-alone installer or archive to install an engine in addition to Freedoom on GNU/Linux distributions as well, both x86 32-bit and x86 64-bit installations. It should provide the same kind of experience that a software repository would give, setting up the shell script in the proper location and adding desktop files.
The text was updated successfully, but these errors were encountered: