search

MovingBlocks / Terasology

Terasology - open source voxel world
http://terasology.org
Apache License 2.0
3.65k stars 1.33k forks source link

Distributing packages to linux distros #4952

Open DarkWeird opened 2 years ago

DarkWeird commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

Hi @jdrueckert and @DarkWeird,

I had a setup of

Why is it not up to date?

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 commented 2 years ago

@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 commented 2 years ago

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

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 commented 2 years ago

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 commented 2 years ago

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:

Cervator commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

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 commented 2 years ago

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:

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

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

Related Issues

qwc commented 2 years ago

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 commented 2 years ago

I tried https://github.com/flatpak/flatpak-builder-tools/issues/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 commented 11 months ago

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 commented 10 months ago

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.