Page 1 of 2
Make maintaining and running oolite easier for everyone
Posted: Tue Mar 10, 2026 2:13 pm
by 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
Re: Why does oolite need flatpak, appimage , sharun etc ?
Posted: Tue Mar 10, 2026 2:48 pm
by MrFlibble
Lone_Wolf wrote: ↑Tue Mar 10, 2026 2:13 pm
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.
Re: Why does oolite need flatpak, appimage , sharun etc ?
Posted: Tue Mar 10, 2026 10:01 pm
by mcarans
Lone_Wolf wrote: ↑Tue Mar 10, 2026 2:13 pm
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.
Re: Why does oolite need flatpak, appimage , sharun etc ?
Posted: Wed Mar 11, 2026 2:30 pm
by Lone_Wolf
Those are the reasons I expected, thanks for the clarification .
Next post will have some suggestions.
Re: Make maintaining and running oolite easier for everyone
Posted: Wed Mar 11, 2026 3:05 pm
by 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
Re: Make maintaining and running oolite easier for everyone
Posted: Wed Mar 11, 2026 7:54 pm
by hiran
Lone_Wolf wrote: ↑Wed Mar 11, 2026 3:05 pm
[...]
- 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
Re: Make maintaining and running oolite easier for everyone
Posted: Fri Mar 13, 2026 5:45 pm
by mcarans
Lone_Wolf wrote: ↑Wed Mar 11, 2026 3:05 pm
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.
Re: Make maintaining and running oolite easier for everyone
Posted: Fri Mar 13, 2026 7:28 pm
by Lone_Wolf
hiran wrote: ↑Wed Mar 11, 2026 7:54 pm
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.
Re: Make maintaining and running oolite easier for everyone
Posted: Fri Mar 13, 2026 7:32 pm
by hiran
Lone_Wolf wrote: ↑Fri Mar 13, 2026 7:28 pm
hiran wrote: ↑Wed Mar 11, 2026 7:54 pm
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?
Re: Make maintaining and running oolite easier for everyone
Posted: Fri Mar 13, 2026 7:57 pm
by Lone_Wolf
mcarans wrote: ↑Fri Mar 13, 2026 5:45 pm
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.
Re: Make maintaining and running oolite easier for everyone
Posted: Sat Mar 14, 2026 12:03 pm
by 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.
Re: Make maintaining and running oolite easier for everyone
Posted: Sat Mar 14, 2026 6:42 pm
by mcarans
Lone_Wolf wrote: ↑Fri Mar 13, 2026 7:57 pm
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 wrote: ↑Sat Mar 14, 2026 12:03 pm
...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?
Re: Make maintaining and running oolite easier for everyone
Posted: Sun Mar 15, 2026 12:05 am
by 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.
Re: Make maintaining and running oolite easier for everyone
Posted: Sun Mar 15, 2026 2:44 am
by mcarans
Lone_Wolf wrote: ↑Sun Mar 15, 2026 12:05 am
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
Re: Make maintaining and running oolite easier for everyone
Posted: Sun Mar 15, 2026 9:13 am
by hiran
Lone_Wolf wrote: ↑Sun Mar 15, 2026 12:05 am
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.