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.
I added the arch package because it uses latest system libraries as much as possible and should give early warnings when newer versions of deps break things. That will help to add max versions of deps where needed and make clear what technical debts we're encountering .
I do agree a source build on something that remains stable should be added, but doubt that ubuntu lts is suitable .
Reasoning :
Ubuntu LTS has 10 year support and won't get newer versions of software then those its released with .
Past experiences from other projects have shown that using ubuntu lts as base is likely to require maintaining separate builds for all lts releases .
This may even lead to having to drop older lts versions from support way before canonical stops supporting them.
Debian stable is supported actively for 3 years ( + 2 years lts support) and has the option to add (a selection) of newer sw versions from testing/unstable .
Using that as base will give a lot more flexibility.
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.
I added the arch package because it uses latest system libraries as much as possible and should give early warnings when newer versions of deps break things. That will help to add max versions of deps where needed and make clear what technical debts we're encountering .
I do agree a source build on something that remains stable should be added, but doubt that ubuntu lts is suitable .
Reasoning :
Ubuntu LTS has 10 year support and won't get newer versions of software then those its released with .
Past experiences from other projects have shown that using ubuntu lts as base is likely to require maintaining separate builds for all lts releases .
This may even lead to having to drop older lts versions from support way before canonical stops supporting them.
Debian stable is supported actively for 3 years ( + 2 years lts support) and has the option to add (a selection) of newer sw versions from testing/unstable .
Using that as base will give a lot more flexibility.
Well I sound locked on Ubuntu - and that is based on availability. Github provides runners based on Ubuntu. Who maintains other environments to check dependencies and functionality?
No surprise there as the ties between Microsoft and Canonical appear to be getting getting stronger almost every month.
Github does support self-hosted runners, mcarans has setup atleast 2 : fedora & archlinux . adding debian stable should not be hard.
There are also git hosters that offer more linux flavors like sourcehut
Maybe adding an oolite mirror outside of github would be a good idea ?
If dep versions on ubuntu LTS 22.08 will become the baseline, better invest time in improving oolite appimage as that has the biggest chance of being able to run on many distros / versions .
Doing that would essentially be a continuation of the linux-deps method in a more modern form.
Github does support self-hosted runners, mcarans has setup atleast 2 : fedora & archlinux . adding debian stable should not be hard.
Great mcarans achieved this. I do not question that self-hosted runners can be created. But someone needs to host them. Otherwise the support will have to be dropped, too.
There are also git hosters that offer more linux flavors like sourcehut
Maybe adding an oolite mirror outside of github would be a good idea ?
There is something inbetween. We could try running docker containers on Github runners. Our build scripts would look slightly more complex. But overall the infrastructure should be easier to maintain, even if some single person leaves the project.
If dep versions on ubuntu LTS 22.08 will become the baseline, better invest time in improving oolite appimage as that has the biggest chance of being able to run on many distros / versions .
Doing that would essentially be a continuation of the linux-deps method in a more modern form.
As much as I understood in Linux you should compile on older versions to be sure of compatibility to newer versions. I may be wrong here.
But regardless of the old or new version - you wanted a stable baseline, didn't you?
Github does support self-hosted runners, mcarans has setup atleast 2 : fedora & archlinux . adding debian stable should not be hard.
Great mcarans achieved this. I do not question that self-hosted runners can be created. But someone needs to host them. Otherwise the support will have to be dropped, too.
There are also git hosters that offer more linux flavors like sourcehut
Maybe adding an oolite mirror outside of github would be a good idea ?
There is something inbetween. We could try running docker containers on Github runners. Our build scripts would look slightly more complex. But overall the infrastructure should be easier to maintain, even if some single person leaves the project.
If dep versions on ubuntu LTS 22.08 will become the baseline, better invest time in improving oolite appimage as that has the biggest chance of being able to run on many distros / versions .
Doing that would essentially be a continuation of the linux-deps method in a more modern form.
As much as I understood in Linux you should compile on older versions to be sure of compatibility to newer versions. I may be wrong here.
But regardless of the old or new version - you wanted a stable baseline, didn't you?
Yes, compiling on old Ubuntu is necessary for the standard AppImage to run on older distros but may not be if we switch to producing an AnyLinux AppImage (and of course isn't needed for Flatpak).