Distributing packages to linux distros

[DarkWeird]

We don't distribution to any linux packages. But linux packages known about us.
Some person maintains not official packages (thx to them)
E.g. https://aur.archlinux.org/packages/terasology

Then why don't lead distribution packages?

Pros

1. It is our reputation
2. More gamers and potential developers
3. It is easy to automate

Cons

1. We should made separate role linux distributor(man with linux)
2. We should listen more places(not only github issue) and handles this

Another changes

1. Launcher will less priority at linux

Work plan

1. Found all terasology packages
2. Inspect how they build own packages
3. Blame malicious packages
4. Brave correctly packages(and suggest support by org)
5. Take owning, if mainteiner don't want maintain further, or maintainer was blame at (3)
6. Define linux distributions for terasology distribution
   6.1. already contains packages
   6.2. easy to integrate (flatpack)
7. Provide linux distribution (without windows/macos natives)(gradle work):
   7.1. terasology-bin (releases from github, without natives)
   7.2.terasology-static (releases from github with natives)
   7.3. terasology-git (building from sources)
8. Provide linux packages for defined distributions (at 6)
9. Provide build jobs for update distro's packages (github actions with on release hooks?)
10. Create bridge bots between discord and distro's package issues?

[jdrueckert]

@DarkWeird do you have any idea about

1. How to figure out who currently "maintains" these old ones?
2. How to distribute packages to linux distros properly?

@qwc Would that be a topic you'd be interested in and could see yourself find time for?

[DarkWeird]

@jdrueckert

How to figure out who currently "maintains" these old ones?

Usually every linux package have maintainer field.(archlinux and etc)
Or owner of repo (ubuntu's ppa)

How to distribute packages to linux distros properly?

It is similar maven 's publish and repos.
I think we can setup our CI for it.
But every package manager have self format and rules.

[jdrueckert]

@DarkWeird Thanks for the quick responses 💚

I think we can setup our CI for it.

I would even argue, that we only want to do this for pre-releases and (stable) releases, in which case maybe we could leverage github actions (fyi @skaldarnar) instead 🤔 the trigger would be extremely easy and there might even be respective actions available already, so we don't have to put too much effort into maintaining the setup...

[qwc]

Hi @jdrueckert and @DarkWeird,

I had a setup of

• An own package repository for debian stuff
• Generating packages for
  • Arch Linux
  • Debian derivates (*buntu)
  • Fedora and similar (RPM based)
• Working CI for all of this, with my own jenkins machine
  • (not working anymore of course)

Why is it not up to date?

• Lack of time
• Lack of appreciation
• And with both of it, lack of interest

I even talked to the arch linux package maintainer to take it over at one point in time, which never came.

Then let's discuss how to continue with it...

[jdrueckert]

@qwc Sorry to hear your work wasn't appreciated 😞

We do have a lot of construction site throughout the project and I'm hesitant to open yet another one.
If we do it, then IMO the process should be automatically triggered and ideally reuse existing (external) options to minimize maintenance effort. Hence the suggestion of github actions.

[jdrueckert]

Places with terasology packages I found with a quick Google search:

• ✔️ https://aur.archlinux.org/packages/terasology/ - surprisingly up-to-date (5.2.0 is not there yet, but 5.1.1 is)
• ❌ https://www.ubuntuupdates.org/package/getdeb_games/xenial/games/getdeb/terasology - extremely out-of-date (latest: 1.5.0)
• ❌ https://www.wikidata.org/wiki/Q40882894 - out-of-date (latest: 4.1.0)
• ❌ http://mxrepo.com/mx/testrepo/pool/test/t/terasology/ - extremely out-of-date (latest: 1.2.1), "marked" as testrepo, but still shows up on repology

How can we get especially the out-of-date ones taken down? Find out how to contact the maintainer somehow or are there "central" entities, we could approach using our terasology mail or something to "authenticate"?

[Cervator]

Sadly I suspect trying to clean out old odd packages would be a waste of time - even if we reached out some would certainly be unreachable or a central authority uninterested in the request. We probably would be better off just crowding out the old entries by publishing our own ones regularly. And yep if GitHub actions work for that then excellent 👍

I can recall finding plenty of other spots in the past, package managers or less formal download sites. It'd be like trying to rake the forests :-) Best we just put up signs as-able to point to the right place 😁

The one case where I could see it make sense to reach out is if any of the more notable package managers have a usurper in our namespace and we need to reclaim it somehow. That happens - it took me a year or two ages ago to get a hold of the "terasology" Youtube account, but somehow the user did notice my polite request after a long time :-)

[jdrueckert]

Not sure, but I just stumbled on https://gemfury.com/ - maybe that would be something for us?
Public packages are free, so that might be suitable for us. It seems to provide a yum/apt repo for pre-built deb/rpm packages. From what I read, it's usually not that easy to publish these packages. What do you think @DarkWeird @qwc ?

For arch it seems to be easier, I found the following github actions for example:

• https://github.com/marketplace/actions/publish-aur-package
• https://github.com/marketplace/actions/publish-aur-package-2

[Cervator]

Just glancing at Gemfury I'm not sure how "official" their hosting would be within the context of a given distro? With our Artifactory updated to Nexus one day we could self-host piles of Linux package management artifacts, but a user would have to first manually add our dist repo (the Nexus instance) to their package manager index.

My impression (which may be out of date) is that the major distros (like that Arch one) have their own third party package manager repos that are either included by default or very commonly set up by users of their distro. I think ideally we'd try to get a process set up to automatically publish Terasology (and DestSol maybe eventually?) to just those "easy to reach" places - akin to publishing binaries to Maven Central rather than your own 3rd party artifact repository.

Beyond that - there are so many (game) hosting services, but they lose relevance very fast IMHO. We should probably just pick and focus on the most popular 5-10 places (including places like IndieDB maybe?) unless we feel like we have the effort available to reach for more?

[DarkWeird]

@jdrueckert @skaldarnar
We can update launcher to java 14 and (j)package launcher in rpm/deb with it.
(Also dmg and exe/msi)

Why launcher. Not game?
Because update launcher is easier then full game. And we still can update game from launchee

[qwc]

Regarding the automation for multiple linux distributions. I had found a tool, back in the day, which could forge from the same source multiple distribution packages (.tar.xz, .deb, .rpm, and even more) (Arch linux, debian based, rpm based, and more).
I somewhere have a repo about it I think... lemme check... -> https://github.com/qwc/terasology-packaging

Of course it's hopelessly outdated. If we could model that with modular github actions, it would be great of course. No resource usage on my machine and maybe even more modular, having a github action for one packaging format. Even a chocolatey package would be an option, IMHO.

[qwc]

Regarding the package repositories or providing the packages, I would suggest to use the most common or advised way by the community.

For *buntu and debian, I would go with a launchpad ppa repository.
Archlinux obviously an aur package, until it's voted into the main repos.
For redhat/fedora/rpm based, I have no idea what's the advised way.

If we ever do a chocolatey package for windows, there we have to research that aswell.

Oh and as i was just looking into the old repo again.
I also thought of

• flatpak
• AppImage
• Snap
• and even Gentoo

My goal back in the day was, to just service all packaging providers existing, with the best minimal effort. More like have a stone in everyone's door and everyone can choose the package format they like the most.

If I would be asked to roll this up again.
I woudl start with having a github action for each package format (as modular as possible).
If there's no github action, I would write my own (as generic action).
Serving the stuff in the way the distribution landscape awaits, or in terms of the flatpak, AppImage and Snap as direct download on the website or github releases itself.
Maybe even github provides something like a PPA repository as known by launchpad?

[skaldarnar]

Disclaimer: I don't want to sound rude, just trying to get all my thoughts (and opinions) out real quick.

First of all, while I like the idea of having officially maintained packages, I don't think this is the right time to talk about it. Here's why:

• it is currently nowhere on our org agenda, and we're spreading thin already without any additional topics
• before creating more accounts and maintaining more things I believe we should solve/agree on some organizational and technical aspects to avoid loosing track or having a bad bus factor
  • I'd like to have an overview of official Terasology Foundation accounts, preferably with login details shared between the active maintainers. I proposed a password storage for this (making sure we rotate credentials regularly). There are other options, but looking into this in detail will take time.
    On a note: I created an account for Snap some time ago, but we never followed up on (a) sharing credentials and (b) trying to build such a package.
  • I'd like to get our versioning settled, because it would be a huge mess if we switch versioning scheme and trying to align that with a bunch of additional package repositories. We're even struggling to feed our own launcher with a single source of truth, tbh.
• we should figure out whether we want to distribute the launcher (which in turn downloads and starts the game) or the game directly.
  • if we want to distribute the game directly, we have to make sure that we have a proper dependency on a Java runtime. Things might have improved in the meantime, but when we looked at Linux packages some time back we had the problem that "just depending on a JRE" wasn't enough, and lead to a lot of trouble in some distros.
  • in general, doing it "the *nix way" by re-using other packages (such as JRE) might lead to issues with incompatible JREs, or even missing pieces (like for JavaFX when not using Oracle's JRE).
  • if we want to distribute the launcher, we should first fix the installation process and what the launcher does internally to make it work properly on Linux. Maybe writing down official installation instructions that match typical best practices would be a good start (I don't think that "extract the ZIP in you 'Downloads' folder and run the shell script" is a good installation instruction).

I'd prefer to have the launcher distributed, and have it as central management tool for downloading and starting the game on all platforms. this gives us control over

• where exactly the game files come from
• which game bundles are available to players
• which JRE (and probably other dependencies) is used

Furthermore, it decouples the update process of the game, and easily allows players to have different game versions installed.

---

Related Issues

• Jenkins omega build has no versionInfo.properties artifact Terasology/Index#16
• Technology for workspace management and release tooling #4035

[qwc]

For end-users (players) it's good to only have the launcher distributed. It solves us the java dependency problem.

But for users who are more experienced and want to run a server, the launcher is not an option. So here it might be a good idea to distribute packages called terasology-server or terasology-dedicated-server, where we also already provide common server settings probably.
And for the docker guys we have the docker image already anyway.

Anyway, my approach was to package everything, the game and the launcher, stripping it down to the launcher, just makes it one less package for everything, the background work is the same.

[Mailaender]

I tried flatpak/flatpak-builder-tools#37 but without much success so far.

Not building from source and using the Java runtime from @flathub might fail due to the game requiring a writable destination. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=terasology#n59 /app/share is read-only. Everything has to land in $HOME/.terasology instead.

[Soundtoxin]

I've been wanting to try this game out for a while but lack of packaging on Guix and other things I use has held me back. I don't usually like Flatpaks, but one advantage to having one is that Steam Deck users could easily install the game from KDE Discover in Desktop Mode.

[qwc]

Reviving the packaging with the fpm tool (https://github.com/jordansissel/fpm) at least for linux doesnt seem to difficult.

When we next think (not only dream) about packaging the game again, I would still opt for trying to kill as much flies with one bat as possible and provide as much package variants we can think of.

The simple reason is: Availability!

On the more packaging types we're available, the more people might simply try it out.
Only requirement is a stable interface from the release builds to the packaging step with all necessary data.