F42 Change Proposal: Replace SDL 2 with sdl2-compat using SDL 3 (self-contained)

Project Discussion Change Proposals
,
1

Replace SDL 2 with sdl2-compat using SDL 3

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

This Change proposes to replace SDL 2 with sdl2-compat, which uses SDL 3.

:link: Owner

:link: Detailed Description

SDL 2 feature development ended some time ago with efforts being focused on SDL 3. However, many older games still use SDL 2 and cannot change to SDL 3. In order to continue to support SDL 2 games in the modern world, let’s replace SDL 2 with sdl2-compat, which uses SDL 3. This also has the effect of moving SDL 1.2 games to SDL3 through sdl12-compat running on sdl2-compat.

:link: Feedback

:link: Benefit to Fedora

Switching SDL 2 powered games to use sdl2-compat ensures that SDL-based applications continue to use the actively developed codebase. This also has the effect of SDL 1.2 powered games that use sdl12-compat to run on SDL3 as well through the fully supported path of sdl12-compat running on sdl2-compat running on SDL3.

:link: Scope

  • Proposal owners:

  • Other developers:

  • Release engineering: #12485

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy: N/A (not needed for this Change)

:link: Upgrade/compatibility impact

The SDL2 package would be transparently upgraded to libsdl2-compat package and games using it should just transparently start using SDL 3.0.

:link: How To Test

The testing steps are simple:

  1. Enable the SDL2onSDL3 COPR: dnf copr enable ngompa/SDL2onSDL3

  2. Swap SDL2 for sdl2-compat: dnf swap SDL2 sdl2-compat

  3. Run something that uses SDL 2 like supertuxkart and see that it works.

  4. Run something that uses SDL 1.2 like icebreaker and see that it works.

Issues should be reported upstream for the fastest response: Issues · libsdl-org/sdl2-compat · GitHub

:link: User Experience

There shouldn’t be a noticeable user impact, other than possibly a smoother experience because applications are using SDL 3.0.

:link: Dependencies

:link: Contingency Plan

  • Contingency mechanism: Revert back to shipping SDL2 / mingw-SDL2 packages
  • Contingency deadline: Final Freeze
  • Blocks release? N/A (not a System Wide Change)

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

Applications that use SDL 2 will now transparently use SDL 3 through the sdl2-compat package. This makes it so applications that historically used SDL 2 now use SDL 3.

Last edited by @amoloney 2024-12-03T18:23:06Z

Last edited by @amoloney 2024-12-03T18:23:06Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I’m strongly in favor if this makes IceBreaker start working again without me having to figure out what is actually wrong with the code! :slight_smile:

1 Like
4

Alas, no. It’s still broken before and after. I did post a new comment about it in the sdl12-compat bug: more icebreaker issues (crash on startup) · Issue #304 · libsdl-org/sdl12-compat · GitHub

5

Well, apparently I’m wrong. Here’s a bug fix for @mattdm.

Upstream: Rename flock to pg_flock to fix symbol conflict with Mesa by Conan-Kudo · Pull Request #17 · mattdm/icebreaker · GitHub

Fedora updates:

1 Like
6

This change proposal has now been submitted to FESCo with ticket #3301 for voting.

To find out more, please visit our Changes Policy documentation.

7

This change has been accepted by FESCo for Fedora Linux 42. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

8

The mupen64plus package just failed to build, could that be due to this change? Maybe someone here has a quick idea on how to fix it before I dig deeper?

https://koschei.fedoraproject.org/build/19455245

Edit: I already tried the error message’s suggestion to build with USE_GLES=1 but that failed with a similar error message suggesting to turn it back to 0.

9

Could you please file an issue with sdl2-compat about this? It seems like we’re missing a definition somewhere that should already be there.

10

@dreua I’ve backported a fix made by upstream for this issue. I’ve pushed a build just now, so you can see if it fixes it in Koschei.

11

Thanks for taking care of this so quick! I’ll be on the lookout if it gets fixed by your backport and report back :+1:

12

I needed to add two imports and change the order of a third, now it builds in rawhide :slight_smile:

I really have no clue whether those are due to sdl2-compat or glibc 14->15 or something entirely different. Looked like mistakes in the mupen souce to me, therefore I patched them there here in Fedora and openend PRs upstream as well.

Let me know if you want this to be reported to sdl-compat as well.

13

That looks like GCC fallout rather than sdl2-compat fallout.