Packaging for Linux

[KaldNL]

This isn't a bug report/feature request, but rather suggestions for how to do things on Linux when OpenJK is released.

Ideally, on a Linux system, individual applications are not updated by themselves. This is why we have package managers; they handle updates, software installation/removal, etc. So, having an updater for OpenJK on Linux isn't a good idea. You'll need to package OpenJK for a specific distribution/package manager. This resolves dependencies and makes everything very easy for the user.

Fragmentation is not an issue. Most desktop Linux users (especially ones who would be playing games) are using Ubuntu. Ubuntu is based on Debian, using Debian's software repositories (sid for standard releases, testing for LTS). So there are a few options here:

1- Make a .deb package for Ubuntu users to download. This will also be compatible with other popular Linux distributions such as Linux Mint, elementaryOS, etc. A PPA (Personal Package Archive) on Launchpad would be very ideal, as users can just have the latest OpenJK updates dealt with by their package manager. Drawback here is that it's very Ubuntu-specific.

2- Make sure the code is entirely pure and try to get it accepted into the Debian repos. Debian has very strict guidelines, but whatever is accepted into Debian automatically gets trickled down into the countless Debian-based distributions including Ubuntu and its derivatives. Drawback here is that packages in Debian are usually older, so users may not have the latest version of OpenJK.

3- Offer a .run installer or similar. Not as nice, but mostly distribution-independent.

Other Distributions (non-Ubuntu, non-Debian).

Popular desktop distributions that aren't related to Ubuntu or Debian are Fedora, OpenSUSE, and Arch. Fedora and OpenSUSE are both RPM distributions, so creating a .rpm package should work for both. Arch users don't need help, and they've already packaged OpenJK: https://aur.archlinux.org/packages/openjk-git/

Options for RPM:

• Use OpenSUSE's build service. Fedora users can also use packages from this.
• Similar to the Debian approach, try to get OpenJK included in the Fedora/OpenSUSE repositories.
• Just offer a .rpm and hope it works for RPM distributions.

My opinion:

View Ubuntu as the default Linux distribution (like it or not). Either get OpenJK included in Debian, or make a .deb package for Ubuntu users (preferably with a PPA). Along with that, simply have available a .zip or .tar.gz for non-Ubuntu distributions. Not required, but still nice, would be to include a .rpm for Fedora/OpenSUSE users. Users of other distributions such as Arch, Gentoo, etc, can take care of themselves.

[archseer]

Or just leave it as is, and users can compile it in two terminal lines...

Is it really that hard to do this?

mkdir build; cd build; cmake ..; make

[setlec]

total waste of time for our devs. just clone the src code repo and compile or wait for stable release. distros might be interested to package openjk but i really doubt that would happen. src code is GPL not the content/assets.

[nanonyme]

@setlec I just recently found this project and that was actually the question I wanted to ask about the situation with content/assets. How "free" are they currently? (as in, is there limitations to redistribution etc) I'm not suggesting here that OpenJK devs should package this, just gathering some background information for if I or someone else would be willing to push this as RPM in eg Fedora's RPMFusion. Everything not being GPL is not a problem there, things not being allowed to be distributed at all would be.

[xycaleth]

Players still need to have a full copy of the original game for the assets. The only thing that would be distributed if we were to go down this route, would be the executables to play the game.

[ensiform]

Can distribute assets3.pk3 (the 1.01 patch, though)

[nanonyme]

@ensiform I guess that could work. It's not unheard of distros would package game engines separately from said assets, like eg with doom engines. Additionally that one later got free assets in form of freedoom. (though obviously easier if free assets for OpenJK would already exist as a separate project or whatever) That said, if someone built free assets, it probably could not be a Star Wars (tm) game but just a game that took advantage of the engine functionality. Will have to think about this further.

[HEXcube]

OpenJK is now available for Ubuntu on Playdeb repo! :-) Check it out - Link to OpenJK on Playdeb . It's available for Ubuntu 14.04LTS "Trusty Tahr" and up. Here's the deb packaging source for trusty - https://github.com/ckorn/PlayDeb/tree/trusty/openjk . Say thanks to Playdeb maintainer Christoph Korn (ckorn on GitHub)! However, OpenJK isn't on official Ubuntu repos yet. But there's no need to worry, coz maintainer Simon McVittie (smcv on Github) is working on getting openjk accepted into Debian - Link to openjk Debian package git repo. Once the package lands in Debian, OpenJK will make it into Ubuntu too like @KaldNL said. But still, an official PPA would be better to provide latest openjk updates. @setlec Content/Assets not being open isn't a problem. Like @nanonyme mentioned, many Linux distros distribute open sourced idTech engines (various games in Quake and Doom series) without the non-free data. However, such games would eventually get the missing data provided by some open content project (for eg; OpenArena, FreeDoom, etc). So, let's hope to see something like OpenAcademy or OpenKnight soon! :-)

[ensiform]

Open assets are unlikely at this point.

There's no interest in anyone putting that much work in.

[xycaleth]

Opening this issue back up because I want see OpenJK being able to create deb and rpm packages "out of the box" at some point in the future.

We (as the core maintainers) might not know how to, but having an open issue at least invites others to submit pull requests :)

[hasufell]

IMO, packaging should be left to the distribution maintainers/contributors. Upstream shouldn't bother with it (and there are a lot of mistakes one can do). If the build system doesn't have major quirks, then it should be fine.

[leilei-]

^ same. Chiming in from the OA front here, people are frustrated that a voluntary packaging accident (on our end) caused frustration for Linux users and how i'm satan for using Windows to develop etc, all because someone didn't chmod u+x.

And Free media is very unlikely because the compatibility aim would be very difficult with the production of new player animations/skeleton from scratch., It would most likely have conflicting bone hierarchy and screw over every addon and mod out there.

..and then there's the creative process where it'd have to try hard to NOT be a Star Wars game while keeping everything that defined JK2/JKA as a game. In my own working base prototype which never worked I had to resort to the term "shaftpole squires"

[Mailaender]

There is https://software.opensuse.org/package/OpenJK now. Source for the RPM is available at https://build.opensuse.org/package/show/games/OpenJK The only thing bothering us is no tagged releases, time/date in the binaries requiring a patch for reproducible builds and make install not adhering fully to FHS as usual from idtech3 clones leading in those dirty wrapper scripts. We could contribute the .desktop files to this repository.

[Mailaender]

For the non-free game data problem there is https://wiki.debian.org/Games/GameDataPackager where Jedi Knight is already supported according to https://pkg-games.alioth.debian.org/game-data/

[HEXcube]

It's been many years since this issue was filed and a lot have changed in Linux packaging during this time. Cross-distro Linux packages are now possible with snaps and flatpaks. :relaxed:

[ensiform]

Snaps aren't likely long for this world even if they seem to be popular for the moment.

[HEXcube]

Maybe... if not snap then flatpak, but there'll be a cross-distro package anyway

[hasufell]

There is no proper way to be cross-distro without circumventing the distro packager manager or using wild containerization techniques.

You can also just provide an in-place installation, bundled as tar.gz and call it cross-distro. No need to go with the latest hypes.

[HEXcube]

You can also just provide an in-place installation, bundled as tar.gz and call it cross-distro

With tarballs, it's a manual installation, not a Linux package. The user'll have to manually extract everything, setup paths, install icons and desktop files.

On the other hand, Snaps and Flatpaks are 'click and install' from GNOME Software or the distro's software store. Like the way Android apps are installed from Play Store.

[hasufell]

With tarballs, it's a manual installation, not a Linux package.

Nothing what you have proposed are linux packages.

The user'll have to manually extract everything

You mean a double click?

On the other hand, Snaps and Flatpaks are 'click and install' from GNOME Software or the distro's software store. Like the way Android apps are installed from Play Store.

That's double click vs single click. Neither of those integrate properly in a cross-distro manner.

[Mailaender]

First step towards a @flathub package would be tagged (stable) releases and an appdata.xml file which adds the metadata for the software store. See https://fedoraproject.org/wiki/Packaging:AppData

[ouned]

You can also just provide an in-place installation, bundled as tar.gz and call it cross-distro. No need to go with the latest hypes.

yeah that's exactly how flatpak and snap work.. educate yourself

[hasufell]

yeah that's exactly how flatpak and snap work..

Not really. They provide containerization/sandboxing. Not sure how you can confuse that with a simple .tar.gz archive.