Control: tags -1 confirmed On 2026-03-12 12:29:09 +0000, Simon McVittie wrote: > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: [email protected], > [email protected] > Control: affects -1 + src:sdl2-compat > User: [email protected] > Usertags: transition > > SDL upstream is in the process of phasing out "classic" src:libsdl2 (an > independent library), replacing it with src:sdl2-compat (a compatibility > shim which dlopens libsdl3 and uses it to implement the SDL 2 API/ABI). > This is very similar to the transition from src:libsdl1.2 to > src:sdl12-compat that we did in trixie > (https://bugs.debian.org/1039911). Faster-moving distributions like Arch > and Fedora have already made this switch, and I think it's time for > Debian to do the same.
Thanks for the detailed plan. Go ahead. Cheers > > This is a "soft" transition with no SONAME bump: the new library is > intended to be fully API- and ABI-compatible with the old (same SONAME, > same pkg-config module name, same CLI interface to the legacy > sdl2-config script, different implementation internally), so it's more > like an unusually intrusive minor-version release. After approving the > transition, the release team will hopefully not need to take any further > action. > > src:sdl2-compat in experimental already implements the proposed design. > > I intend to keep src:libsdl2 in the archive, at least initially: that > way, users who encounter a regression can install the libsdl2-classic > package and force its use via environment variables as documented in > <https://salsa.debian.org/sdl-team/sdl2-compat/-/blob/debian/snapshots/debian/README.Debian?ref_type=heads>. > > It should probably be removed before forky+1, or perhaps before forky if > the transition goes particularly well. > > Risks > ===== > > I did a mass-rebuild, partly on debusine and partly locally or on > porterboxes. All 3 FTBFS bugs found (test failures) have been fixed by > improvements to the affected packages. I've also tested an assortment of > SDL 2 games (and SDL 1.2 games via sdl12-compat), and asked -devel and > the games team to help with testing (back in September 2025) with no > regressions reported as a result. > > As with the SDL 1.2 transition, it isn't really feasible for me to test > every SDL 2 game myself, and I generally haven't been testing non-game > applications that use SDL (many of which are emulators requiring ROMs > that I don't have, or specialized music apps that I don't know how to > use). > > Known regressions are listed here, and at the time of writing have all > been fixed: > <https://bugs.debian.org/cgi-bin/[email protected];tag=regression> > > The API/ABI is the same, but there are various subtle behaviour changes > between libsdl2 and sdl2-compat that could break games' expectations > (especially if they are relying on behaviours that were never intended > to be guaranteed), either as a result of intentional changes or as a > result of SDL bugs. The ones I know about are: > > * "Classic" SDL 2 defaults to X11, via Xwayland if necessary. > sdl2-compat defaults to native Wayland if a sufficiently capable > compositor is detected. This will break games that blindly assume > that Unix implies X11, and could also expose Wayland-related bugs that > were previously hidden, such as <https://bugs.debian.org/1124335>. The > correct fix for a game that assumes X11 is to make the game tell SDL > "use only X11", but for proprietary games or games that are otherwise > hard to modify, sdl2-compat has a "quirks" table that can automatically > force X11 based on the name of the executable. > > * libsdl3 has a Vulkan backend for the rendering API, which sdl2-compat > will use if appropriate. It is unlikely to be perfectly bug-for-bug > compatible with the OpenGL or software backends. If necessary, > sdl2-compat's quirks table can be used to work around this. > > * sdl2-compat has slightly different behaviour around paletted > (256-colour) windows and textures, which caused a regression for the > autopkgtest and build-time tests of the SDL 1.2 Perl binding. I worked > around this in sdl12-compat for now, but when we switch to sdl2-compat > we'll want to do a coordinated upload of sdl12-compat reverting that > workaround. > > The only autopkgtest regression listed in > https://qa.debian.org/excuses.php?experimental=1&package=sdl2-compat is > for yuzu on arm64, but yuzu isn't in testing (*because* it's broken on > arm64, in fact) so this shouldn't prevent transition. > > smcv > -- Sebastian Ramacher
