Vega Strike
2022-12 Platform Support Discussion #750
Replies: 11 comments 27 replies
-
|
For starters, Red Hat Enterprise Linux 9 is out. And 9.1, even. I was unaware of this. Correspondingly, Rocky Linux 9.0 and 9.1 are also out. So are various 8.x point releases of both of them. See https://hub.docker.com/_/rockylinux , for example. |
Beta Was this translation helpful? Give feedback.
-
|
What do we do about all these point releases / minor versions? 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 9.0, 9.1. That's a lot! |
Beta Was this translation helpful? Give feedback.
-
|
Oh, but apparently, only 8.5, 8.6, and 9.0 have official Rocky Linux images available on Docker Hub. |
Beta Was this translation helpful? Give feedback.
-
|
Let's keep it to what Rocky Linux has official, live support for - so 8.5, 8.6, and 9.0. |
Beta Was this translation helpful? Give feedback.
-
|
Fedora 37 has also been released. Linux Mint 21 and 21.1, as well. |
Beta Was this translation helpful? Give feedback.
-
|
RHEL 9 includes CMake 3.20.2. It not only supports it, but includes it installed by default, if I understand correctly. |
Beta Was this translation helpful? Give feedback.
-
|
Should we consider that a strong hint to make CMake 3.20 our new minimum required version? And use pip to install CMake where needed on older distros, like we discussed? |
Beta Was this translation helpful? Give feedback.
-
|
We're already using a tool on some platforms to use newer versions of CMake as we ruled it's a build environment tool and not necessarily a platform tool for the delivery of the product. So as long as we can get it on all our supported platforms we should be good to upgrade CMake to newer versions, whether that is with the pip tool we've been using or (preferably) with native support. The pip tool probably only works for Linux - we should implement some kind of matrix tracking, or perhaps build a tool to generate a matrix that we can run periodically (GH action?) to determine what we can update to. |
Beta Was this translation helpful? Give feedback.
-
|
How do you foresee that tool and matrix working? Maybe run a shell script on each platform we're interested in, and upload the result of |
Beta Was this translation helpful? Give feedback.
-
|
@stephengtuggy not sure...open to ideas. We probably need to include the CMake version in a matrix on what platforms we support. If it's possible to do that dynamically then we could tie it into the build system like you suggested; but that's probably going to have to be something that we build on the side to support and run, perhaps in our Digital Ocean space. |
Beta Was this translation helpful? Give feedback.
-
|
As for Ubuntu Xenial, it's kaput. I can't get its Docker image to build anymore. Nor hirsute nor impish, either. |
Beta Was this translation helpful? Give feedback.
-
|
yes, we need to update to newer versions. I'm also running Pop! OS and saw some discussion on IRC about others trying it - there's some minor differences in OS detection ( which I think I've added on the master branch) so we should make sure those are incorporated too. PopOS is Ubuntu based so we should generally be okay with deliverables As-Is, it's just the build setup for custom compiles that we need to make sure is supported. |
Beta Was this translation helpful? Give feedback.
-
|
Pop! OS feature request filed as vegastrike/build-system-docker-images#35 |
Beta Was this translation helpful? Give feedback.
-
|
@BenjamenMeyer Can you do me a favor, and run the following in bash on your Pop! OS system? Then I can use the output to start working on adding support for it: if [ -f /etc/os-release ]
then
OS_RELEASE_LOCATION="/etc/os-release"
elif [ -f /usr/lib/os-release ]
then
OS_RELEASE_LOCATION="/usr/lib/os-release"
else
echo "os-release file not found; unable to continue"
exit 1
fi
LINUX_ID=$(grep ^ID= $OS_RELEASE_LOCATION | sed 's/^ID=//' | tr -d '"\n')
echo "LINUX_ID = ${LINUX_ID}"
LINUX_CODENAME=$(grep ^VERSION_CODENAME= $OS_RELEASE_LOCATION | sed 's/^VERSION_CODENAME=//' | tr -d '"\n')
echo "LINUX_CODENAME = ${LINUX_CODENAME}"
LINUX_VERSION_ID=$(grep ^VERSION_ID= $OS_RELEASE_LOCATION | sed 's/^VERSION_ID=//' | tr -d '"\n')
echo "LINUX_VERSION_ID = ${LINUX_VERSION_ID}" |
Beta Was this translation helpful? Give feedback.
-
|
Copy-paste-run, also output of $ if [ -f /etc/os-release ]
then
OS_RELEASE_LOCATION="/etc/os-release"
elif [ -f /usr/lib/os-release ]
then
OS_RELEASE_LOCATION="/usr/lib/os-release"
else
echo "os-release file not found; unable to continue"
exit 1
fi
LINUX_ID=$(grep ^ID= $OS_RELEASE_LOCATION | sed 's/^ID=//' | tr -d '"\n')
echo "LINUX_ID = ${LINUX_ID}"
LINUX_CODENAME=$(grep ^VERSION_CODENAME= $OS_RELEASE_LOCATION | sed 's/^VERSION_CODENAME=//' | tr -d '"\n')
echo "LINUX_CODENAME = ${LINUX_CODENAME}"
LINUX_VERSION_ID=$(grep ^VERSION_ID= $OS_RELEASE_LOCATION | sed 's/^VERSION_ID=//' | tr -d '"\n')
echo "LINUX_VERSION_ID = ${LINUX_VERSION_ID}"
LINUX_ID = pop
LINUX_CODENAME = jammy
LINUX_VERSION_ID = 22.04
$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os |
Beta Was this translation helpful? Give feedback.
-
|
We have also had at least one request for Debian "bookworm" support. bookworm hasn't been finalized yet, but we could probably start adding support for it to our infrastructure. vegastrike/build-system-docker-images#27 does that, as well as making several of the other changes mentioned here, minus Pop! OS support. That last hasn't been added yet. But it would probably make a quick and easy followup PR. |
Beta Was this translation helpful? Give feedback.
-
|
I just tentatively updated https://github.com/vegastrike/Vega-Strike-Engine-Source/wiki/Platform-Support , adding Windows 11 and Visual Studio 2022, along with some proposed changes to the set of Linux distros we support. I also updated the list of CMake versions associated with each distro. Based on this information -- and installing CMake from buster-backports on Debian Buster -- I think we can bump our minimum CMake version up to 3.16 easily enough. After CMake 3.16, Ubuntu Focal and Linux Mint 20 become sticking points. |
Beta Was this translation helpful? Give feedback.
-
|
We could perhaps use the pip installation method again for those, but I'm beginning to have some reservations myself about using pip in too many places. It seems like in some cases, it causes conflicts with system libraries. |
Beta Was this translation helpful? Give feedback.
-
|
yeah, given how new Ubuntu Focal (20.04) is, I'd rather not use the pip tool for it yet. I think that's a tool we can use for the older long term systems like 14.04/16.04 that we still support but are close to being dropped, and perhaps for recommendations for those that we don't officially support (we don't do CI for) but folks want to build on themselves - then they can make the decision of manually installing from source or using the pip tool or another method of getting the tools they desire. Alternatively, we could use our Ubuntu PPA to setup backports for our toolchain and then setup something to do source builds and post a huge caveat about using it, targeting the primary use case of our CI system. That might be a good solution since we won't have to do the builds ourselves or in GitHub. |
Beta Was this translation helpful? Give feedback.
-
|
I know this is a slight change of position from https://github.com/orgs/vegastrike/discussions/750#discussioncomment-4374949, and I think that's okay. In general supporting additional distros is not a huge lift so I kind of lean towards just letting the ball roll as opposed to dropping support entirely. That said, the below is worth discussion: @stephengtuggy how about we reduce the number by reducing duplications a little. The easy way to do that would be to drop point releases of Red Hat based distros (RH, Rocky). We really only need to generate builds for the major releases. The impact would be that we'd have less work to do to maintain the distro list because we would not be updating it for every point release but only when the major version changes. For the build systems we would reduce our images for those distros to just the major generic builds which should match the latest point release. So for example, with Rocky Linux we would drop the 8.5 and 8.6 images and just use a RL 8 image. NOTE: When I was checking on Rocky Linux the other week it seems they may be doing that any way so we may not be able to support RL point releases any way; however I still think this would be a good idea for our overall RH-based distro support. NOTE: OpenSuSe seems to only support the last 2 point releases. NOTE2: For Ubuntu we typically have the 6 month releases between LTS releases in so that we can support the next LTS release...and I usually have that as my build platform any way. It helps, but if needed we could just limit to the LTS releases there too. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good. |
Beta Was this translation helpful? Give feedback.
-
|
On second thought, that might not be so good for compatibility purposes for some of our older releases, like v0.8.x of the Vega Strike Game Engine. We probably need to specify the major and minor version numbers still (i.e. 9.2), but just keep them a little more up to date. |
Beta Was this translation helpful? Give feedback.
-
|
@stephengtuggy how about we roll to that when we release 0.9.x? So keep the status quo while 0.8.x is our release and 0.9.x is in development, and then with 0.9.x we switch it all up. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, I just noticed this morning: Apparently 0.8.x still just specifies Rocky Linux as So why don't we decide on what format we want to use, and then change both 0.8.x and the master branch to align with that, at the same time? |
Beta Was this translation helpful? Give feedback.
-
|
I was going to say that specifying only the major version number, such as Rocky Linux |
Beta Was this translation helpful? Give feedback.
-
|
I don't think (well, You) need to support any Linux distribution. We should be focusing on the core code itself. Whether something runs on Debian this or RHEL that is up to the package maintainer of the specific distro. This is a question of priorities and impact. If we focus on the game and make it more compelling, we'll get other people's attention and good will. That will get more volunteers. One of them can do this. |
Beta Was this translation helpful? Give feedback.
-
|
@royfalk yes I agree. Our real only support is providing the binaries in the builds and releases, which is mostly because we get stuff more for free (as in really low hanging fruit to do so). Mac and Windows will require a bit more effort and getting that out will require that we do some support so we can get the audience to use it; but after that it should mostly be about focusing on the game itself to deliver an excellent engine and game experience. As it is now, we don't provide Arch binaries but the community has stepped up to do so. It'd be great to see the same with other distros as well, and awesome if we got some dedicated Windows and Mac devs in too. |
Beta Was this translation helpful? Give feedback.
-
|
Roy, I wholeheartedly agree.
|
Beta Was this translation helpful? Give feedback.
-
|
Just a thought... The various Linux distributions might be more inclined to make their own packages if the VegaStrike source is simple and easy to compile, the game assets up to date and the game is fun to play. In short, if you build it, they will come... to borrow from Wayne's World. :) |
Beta Was this translation helpful? Give feedback.
-
|
@evertvorster that's the long term goal. We have a ways to get there. I'm looking to change up our CMake stuff a little to make it easier as well. We've just got quite a bit of refactoring to get to that point, which will also improve stability too. |
Beta Was this translation helpful? Give feedback.
-
|
@evertvorster I agree, in general. I think we share the same goals as far as a playable, fun, and easy-to-work-with game and game engine. It's just that sometimes, there have been unforeseen challenges that have come up in practice. The CI builds for all the different Linux distributions were supposed to contribute to those larger goals, not detract from them. And I think they are more or less doing that again now. You can look at my comments here as well, related to this topic, if you like. |
Beta Was this translation helpful? Give feedback.
-
|
P.S. Apologies for taking so long to reply! |
Beta Was this translation helpful? Give feedback.
-
|
November 2023 update:
|
Beta Was this translation helpful? Give feedback.
-
It's time to discuss and update our Platform Support List, adding new OS releases and dropping EOL ones. (Follow-up to #645)
Beta Was this translation helpful? Give feedback.
All reactions