Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Guillem Jover]

Hi!

On Sun, 2021-03-21 at 14:03:32 +0100, Stephen Kitt wrote:
> 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 +, Simon McVittie  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.

Sure, in my case sway, but all the same. My goal is to be able to
disable Xwayland completely though. :)

> > You can override this with with environment variable
> > SDL_VIDEODRIVER=wayland.

Yes, the problem though is that this cannot be set unconditionally in
one's environment, as any SDL-1 program will then fail to start
completely (some might even segfault if they are not checking the SDL
initialization function return codes, as I found out with hex-a-hop,
which should now be fixed upstream :).

> Right, I’ll make sure to document this in the package.

Please, document that setting this unconditionally is currently not a
good idea.

> > 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.

Right, sorry should have made this more clear in the RFP.

There was also , which seems might
have been more complete, but given that it does not seem to be active
anymore and not maintained by upstream SDL, it was not worth pursuing.

Thanks,
Guillem

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Stephen Kitt]

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 +, Simon McVittie  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 
> (no content yet though).

Thanks!

Regards,

Stephen


pgpKWdE8uBbdi.pgp
Description: OpenPGP digital signature

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Simon McVittie]

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.

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.

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.

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.

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 
(no content yet though).

smcv

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Stephen Kitt]

On Sat, Mar 13, 2021 at 11:47:30PM +0100, Guillem Jover wrote:
> * Package name: libsdl1.2-compat
>   Version : 0.0~git
>   Upstream Author : Ryan C. Gordon 
> * URL : https://github.com/libsdl-org/sdl12-compat
> * License : zlib/libpng
>   Programming Lang: C
>   Description : SDL 1.2 binary compatibility library wrapping SDL 2.0
> 
> This code is a compatibility layer; it provides a binary-compatible API for
> programs written against SDL 1.2, but it uses SDL 2.0 behind the scenes. If
> you are writing new code, please target SDL 2.0 directly and do not use this
> layer.

I’m interested in maintaining this, I’ll ask to join the SDL team.

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Haelwenn (lanodan) Monnier]

Hi,

gentoo contributor that saw this bug on IRC so not a debian point of 
view but a warning:

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

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Guillem Jover]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-sdl-maintain...@lists.alioth.debian.org, 
debian-devel-ga...@lists.debian.org

* Package name: libsdl1.2-compat
  Version : 0.0~git
  Upstream Author : Ryan C. Gordon 
* URL : https://github.com/libsdl-org/sdl12-compat
* License : zlib/libpng
  Programming Lang: C
  Description : SDL 1.2 binary compatibility library wrapping SDL 2.0

This code is a compatibility layer; it provides a binary-compatible API for
programs written against SDL 1.2, but it uses SDL 2.0 behind the scenes. If
you are writing new code, please target SDL 2.0 directly and do not use this
layer.



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.

Unfortunately we have quite many packages still using SDL 1.2, and while
I think I'll start porting them one by one (when time permits), it still
would be nice to get this wrapper packaged so that we can get immediate
results and can stop depending on Xwayland for most of the packages in
Debian.

Thanks,
Guillem