Make maintaining and running oolite easier for everyone

[Lone_Wolf]

I've maintained an oolite AUR package for archlinux from 2006 to 2011 .
From 2011 to 2018 it was included in arch repos and maintained by devs.
In 2018 it was dropped to aur because espeak was dropped to aur and repo pacakges aren't allowed to depend on aur packages.
In 2025 I took over maintenance of the aur oolie & oolite-git packages and managed to get everything working again .

In those 20 years the archlinux oolite package has always used source build and still does .

Most open source games I know of advocate source builds and rely on distro/downstream packagers to provide binaries.
Many also offer generic binaries that can be installed by users. Those generic binaries typically use older dependency versions taken from distros like debian stable.

What is the problem oolite devs try to solve with flatpak , appimage and similar ?

EDIT: thread title changed

[MrFlibble]

What is the problem oolite devs try to solve with flatpak , appimage and similar ?

I too instinctively prefer the use of shared system libs rather than monolithic clunkiness, however:-

flatpak/appimage removes the need to have devs for every distro. Flatpak puts it in the software manager of several distros in one hit.

Appimage allows instant testing of new builds without waiting for package manager to catch up. It's also a really easy way to have multiple installations on the go, so one can test new builds in a new folder without clashes.

There's nothing to stop per-distro curation, nor much cause that for anything but stable releases when there are universal solutions available.

Perhaps the existence of the appimage etc. will cause more dev types to have a look, get interested, and ultimately curate for their distro of choice.

For me, in practise, the difference in performance when building from source using shared libs is negligible.

Of course, in an ideal world, it'd be built native for every package manager on every distro.

[mcarans]

I've maintained an oolite AUR package for archlinux from 2006 to 2011 .
From 2011 to 2018 it was included in arch repos and maintained by devs.
In 2018 it was dropped to aur because espeak was dropped to aur and repo pacakges aren't allowed to depend on aur packages.
In 2025 I took over maintenance of the aur oolie & oolite-git packages and managed to get everything working again .

In those 20 years the archlinux oolite package has always used source build and still does .

Most open source games I know of advocate source builds and rely on distro/downstream packagers to provide binaries.
Many also offer generic binaries that can be installed by users. Those generic binaries typically use older dependency versions taken from distros like debian stable.

What is the problem oolite devs try to solve with flatpak , appimage and similar ?

In a word, time. MrFlibble summed up well.

In a voluntary project with a few developers doing things in their spare time, is it better to spend all available time keeping packages working on a wide variety of distros or to produce one or two package types (like Windows) and try to modernise or improve the game? Doing both is not possible given current resources. People are welcome to step forward to make packages for their particular distro if they wish.

Sharun looks promising because it claims to solve the glibc problem. A build of Oolite with up to date dependencies should work on old distros using that tool.

[Lone_Wolf]

Those are the reasons I expected, thanks for the clarification .

Next post will have some suggestions.

[Lone_Wolf]

First suggestion

Establish a baseline with min/max versions for all external dependencies for all platforms supported by oolite

Second suggestion

Implement a method that verifies which deps + versions are present at install / runtime.
That info should then be compared with the baseline to determine issues.
Outputting the issues should be in a format suitable for reporting them to oolite team.

More advanced versions could try to solve the issues automagickally by using methods native to the runtime platform .


Notes

• This approach won't work unless the entire Oolite dev team supports it.
• baseline should be checked/updated regularly (like once a year) AND before every stable release
• for linux .so-versions of libraries can be used.
  lddtree util from https://wiki.gentoo.org/wiki/Hardened/PaX_Utilities is very good at providing info which deps are missing/present .
• for linux the best native method likely LD_PRELOAD
  see man 8 ld.so for details

[hiran]

[...]

• This approach won't work unless the entire Oolite dev team supports it.

[...]

I'm wondering whom you are addressing. Is it these people?
https://github.com/orgs/OoliteProject/people

[mcarans]

First suggestion

Establish a baseline with min/max versions for all external dependencies for all platforms supported by oolite

Second suggestion

Implement a method that verifies which deps + versions are present at install / runtime.
That info should then be compared with the baseline to determine issues.
Outputting the issues should be in a format suitable for reporting them to oolite team.

More advanced versions could try to solve the issues automagickally by using methods native to the runtime platform .


Notes

• This approach won't work unless the entire Oolite dev team supports it.
• baseline should be checked/updated regularly (like once a year) AND before every stable release
• for linux .so-versions of libraries can be used.
  lddtree util from https://wiki.gentoo.org/wiki/Hardened/PaX_Utilities is very good at providing info which deps are missing/present .
• for linux the best native method likely LD_PRELOAD
  see man 8 ld.so for details

Sounds like it might work. I'm happy for you to produce a prototype to demonstrate that it will work and be maintainable.

[Lone_Wolf]

[...]

• This approach won't work unless the entire Oolite dev team supports it.

[...]

I'm wondering whom you are addressing. Is it these people?
https://github.com/orgs/OoliteProject/people

It's meant for the people that maintain and update oolite.
That's a bit vague, a narrow technical description could be : everyone that has merge rights on OoliteProject.

[hiran]

[...]

• This approach won't work unless the entire Oolite dev team supports it.

[...]

I'm wondering whom you are addressing. Is it these people?
https://github.com/orgs/OoliteProject/people

It's meant for the people that maintain and update oolite.
That's a bit vague, a narrow technical description could be : everyone that has merge rights on OoliteProject.

The effect of what you specified is the same list as I mentioned. Good, we have consensus.
Now we just need these people to sign in blood, right?

[Lone_Wolf]

Sounds like it might work. I'm happy for you to produce a prototype to demonstrate that it will work and be maintainable.

I expect I could design/compose a few specific usecases to clarify the lddtree + LD_PRELOAD approach using manual commands/actions .
Will that do ?

Note : I'd like this thread to focus on the concept so would post that in another thread in the linux forum area.

[hiran]

Coming back to the first suggestion of creating a baseline:

I like the idea of documenting one (to start with) environment where Oolite works and bugs and functionality are tested against. This will make it indeed easier for users and developers.

Then I'd like to move towards suggestion 2 by adding more operating systems, versions and flavors but only as many as the devs can support.

At the same time I'd like to see a defined sequence in which environments can get dropped if the capacity does not allow keeping all.

And yes, it makes sense to review the status quo once in a while.

[mcarans]

I expect I could design/compose a few specific usecases to clarify the lddtree + LD_PRELOAD approach using manual commands/actions .
Will that do ?

Note : I'd like this thread to focus on the concept so would post that in another thread in the linux forum area.

...Then I'd like to move towards suggestion 2 by adding more operating systems, versions and flavors but only as many as the devs can support...

Estimating the support aspect is what I'd like to focus on. Here is my attempt:

Let's say we pick 5 distros and 8 versions per distro (eg. from Ubuntu 22.04 which the appimage is built on until now) to cover several years of distros to get the baseline systems. That means setting up 40 Linux installations. This is to cover the variations in Linux kernel, Wayland versions and other things that aren't direct build dependencies of Oolite.

Now we want to work out the baseline dependencies - I counted 21 (including compiler and linker which are important). For each dependency we want to test versions from a min to a max version. Let's say 5 versions per dependency. That's 105 builds of Oolite followed by launching it 105 times to test it works. But then that needs to be tested on the current and historical Linux flavours so 105x40 = 4200 builds and launches.

That sounds impossible even on a commercial project let alone a voluntary one and presumably isn't what you have in mind. What is the idea for obtaining the baseline?

[Lone_Wolf]

We choose a point in time, focus on known good installations and use those to establish the baseline.

as starting point I suggest oolite 1.92 as that was released 5 weeks ago. As far as I know no critical bugs have been reported since then.

The downloads page shows 1 windows download, a linux flatpak and linux appimage.
We can add my stable oolite aur package as 4th known good install.

The archlinux package uses system libraries for deps that are not built from oolite source, the appimage has most of those librairies in the image and very few that are external to the appimage.

I know very little about flatpaks and I haven't been involved in windows support (3rd line server support) for 15+ years.
My gut feeling is that both flatpak and windows install will be similar to the appimage :
most deps included , only a few things needed from the OS.

The insight I have gained from maintaining oolite on archlinux - and helping to troubleshoot when I wasn't the maintainer - suggests to me Oolite sourcecode is designed with a high level of abstraction and could be compared to a rugged IP68 phone.

I'd be surprised if kernel variations mattered much for running oolite.

As for X / wayland :
oolite 1.92 on linux has a hard dependency on libGLX.so.0 & libX11.so.6 and no wayland specific depends.
That means it will run on X and under wayland it will use Xwayland .


Linkers are tools for creating binaries / libraries and not involved at runtime.
Compilers and their runtime libraries are trickier, but it does look oolite high abstraction level helps a lot there.

[mcarans]

We choose a point in time, focus on known good installations and use those to establish the baseline.

as starting point I suggest oolite 1.92 as that was released 5 weeks ago. As far as I know no critical bugs have been reported since then.

The downloads page shows 1 windows download, a linux flatpak and linux appimage.
We can add my stable oolite aur package as 4th known good install.

The archlinux package uses system libraries for deps that are not built from oolite source, the appimage has most of those librairies in the image and very few that are external to the appimage.

I know very little about flatpaks and I haven't been involved in windows support (3rd line server support) for 15+ years.
My gut feeling is that both flatpak and windows install will be similar to the appimage :
most deps included , only a few things needed from the OS.

The insight I have gained from maintaining oolite on archlinux - and helping to troubleshoot when I wasn't the maintainer - suggests to me Oolite sourcecode is designed with a high level of abstraction and could be compared to a rugged IP68 phone.

I'd be surprised if kernel variations mattered much for running oolite.

As for X / wayland :
oolite 1.92 on linux has a hard dependency on libGLX.so.0 & libX11.so.6 and no wayland specific depends.
That means it will run on X and under wayland it will use Xwayland .


Linkers are tools for creating binaries / libraries and not involved at runtime.
Compilers and their runtime libraries are trickier, but it does look oolite high abstraction level helps a lot there.

Speaking of compilers being trickier, the arch source build just started failing with an error building gnustep-base that I've not seen before: https://github.com/mcarans/oolite/actio ... 7103273305 - is that one you've come across?

Code: Select all

configure: error: Your compiler does not appear to implement the -fconstant-string-class option needed for support of strings.  Please check for a more recent version or consider using --enable-nxconstantstring

[hiran]

We choose a point in time, focus on known good installations and use those to establish the baseline.

as starting point I suggest oolite 1.92 as that was released 5 weeks ago. As far as I know no critical bugs have been reported since then.

The downloads page shows 1 windows download, a linux flatpak and linux appimage.
We can add my stable oolite aur package as 4th known good install.

The archlinux package uses system libraries for deps that are not built from oolite source, the appimage has most of those librairies in the image and very few that are external to the appimage.

I know very little about flatpaks and I haven't been involved in windows support (3rd line server support) for 15+ years.
My gut feeling is that both flatpak and windows install will be similar to the appimage :
most deps included , only a few things needed from the OS.

The insight I have gained from maintaining oolite on archlinux - and helping to troubleshoot when I wasn't the maintainer - suggests to me Oolite sourcecode is designed with a high level of abstraction and could be compared to a rugged IP68 phone.

I'd be surprised if kernel variations mattered much for running oolite.

As for X / wayland :
oolite 1.92 on linux has a hard dependency on libGLX.so.0 & libX11.so.6 and no wayland specific depends.
That means it will run on X and under wayland it will use Xwayland .


Linkers are tools for creating binaries / libraries and not involved at runtime.
Compilers and their runtime libraries are trickier, but it does look oolite high abstraction level helps a lot there.

I think we need to have a direct OS build like Ubuntu 22 LTS as it is the base for AppImage and Flatpak alike. Also Windows should be there. On top of that - and with less priority then the different packaging formats like aur, AppImage, Flatpak, NSIS, MSIX.

As providing these builds and packages shall include testing we need to define what tests shall be executed. Is it just building without error? Do we play the game until end? The truth is in the middle and hopefully we can automate a good part of that.