Control: retitle -1 ITP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0 Control: owner -1 ! On Sun, 21 Mar 2021 11:17:32 +0000, Simon McVittie <smcv@debian.org> wrote: > On Sat, 13 Mar 2021 at 23:47:30 +0100, Guillem Jover wrote: > > I've recently retried switching to Wayland and I think I'm sticking > > with it. But while checking for toolkits support, noticed that SDL 1.2 > > does not have native Wayland support, but SDL 2.0 does. > > Note that SDL 2.0 currently defaults to using X11 if available, and will > currently only use Wayland if X11 is unavailable, so in environments where > Xwayland is either always run (such as GNOME 3.38) or started automatically > on-demand (such as GNOME 40), SDL 2.0 games will normally be using X11. > I think typical desktop environments like GNOME and KDE Plasma are > likely to want Xwayland available by default for quite a long time, > even if it's only started on-demand. > > You can override this with with environment variable > SDL_VIDEODRIVER=wayland. Right, I’ll make sure to document this in the package. > On Sun, 14 Mar 2021 at 02:07:34 +0100, Haelwenn (lanodan) Monnier wrote: > > As seen in [1] regarding the headers, sdl12-compat isn't a full > > replacement yet. > > > > It could work for pure binary-compatibility but you can't build anything > > against it yet so it should be a Provide+Replace rather than something > > like a newer version. > > > > 1: https://github.com/libsdl-org/sdl12-compat/issues/34 > > Yes, I'd come to that conclusion too. Yup, for the time being it’s really only a runtime replacement, it’s not ready as a build-time SDL2 shim for SDL1.2 projects. > If we get to a point where we want to eliminate the original SDL 1.2 from > the archive before sdl12-compat has headers, we could probably make some > sort of hybrid package that builds SDL 1.2, keeps the headers, discards > the actual shared library and uses the shared library from sdl12-compat > instead - but I think it would probably work best to package sdl12-compat > as a separate binary-compatibility-only library first. Yes, that’s my plan at least. If we do end up wanting to drop (or deprecate) libsdl1.2debian, I’m not sure we’d really even need a hybrid package — it would be simpler to make libsdl1.2-dev depend on libsdl1.2-compat instead of libsdl1.2debian... It’s not as if the licensing concerns really affect Debian in this instance, AFAICT. > It would probably be best to have the sdl12-compat shared library installed > in a directory outside the default search path so that it can be > co-installed with the real SDL 1.2, and then insert it into the default > search path in a separate package that Provides/Conflicts/Replaces the > real SDL 1.2. That way, individual games have the option to use sdl12-compat > via DT_RUNPATH or LD_LIBRARY_PATH without preventing co-installation of > the real SDL 1.2. > > In particular, sdl12-compat has a few extra symbols not present in the > real SDL 1.2, which are meant to make it binary-compatible with the > modified SDL 1.2 build "libSDL-1.2.id.so.0" in some id Software games, > such as the quake4-bin:i386 package built by game-data-packager. If > it works well as a replacement for that modified library, then > game-data-packager could prefer to use sdl12-compat. Good point, I hadn’t thought of that. So we’d have a libsdl1.2-compat package usable by packages that explicitly prefer the compatibility layer, and a libsdl1.2-compat-shim (or something like that) package which actually replaces libsdl1.2debian. > On Thu, 18 Mar 2021 at 21:30:47 +0100, Stephen Kitt wrote: > > I’m interested in maintaining this, I’ll ask to join the SDL team. > > I've added you. > > I briefly started looking at this before seeing this message, so I've > created an empty <https://salsa.debian.org/sdl-team/sdl12-compat> > (no content yet though). Thanks! Regards, Stephen
Attachment:
pgpZc7PMCZEZI.pgp
Description: OpenPGP digital signature