Bug#1039911: transition: sdl12-compat taking over libsdl1.2-dev

[Simon McVittie]

On Sun, 16 Jul 2023 at 18:18:09 +0100, Simon McVittie wrote:
> On Sun, 16 Jul 2023 at 18:55:28 +0200, Sebastian Ramacher wrote:
> > Could you check whether that is an issue in sdl12-compat or
> > libsdl-perl?
>
> I already opened <https://bugs.debian.org/1041211> and marked it as
> blocking this transition-tracker bug.

After talking to SDL upstream, it looks as though libsdl-perl was always
doing something that ought to be undefined behaviour (freeing the global
video surface object, which is "owned" by the SDL video implementation),
but an implementation quirk of libsdl1.2 meant that attempting to free
the global video surface was silently ignored.

The regression with sdl12-compat is because sdl12-compat is more likely
to deallocate the global video surface and allocate a new one, whereas
libsdl1.2 would usually keep using the same global video surface for the
lifetime of the process, even if parameters like the colour depth changed.

Possible solutions to continue this transition:

1. fix libsdl-perl (#1041211, RC; I sent a potential patch upstream, but
   I've never tried writing Perl XS bindings before, so I'm not very
   confident that I'm getting it right)

2. work around the issue in sdl12-compat because they aim for bug-for-bug
   compatibility (#1041416, wishlist, also forwarded upstream), after
   which #1041211 can be downgraded to non-RC

3. kick out libsdl-perl, dizzy, frozen-bubble and pangzero from testing
   until at least one of those two bugs can be fixed
   (I've checked with `dak rm -R -n -s testing` that those four source
   packages would be enough)

Or wait until one of those happens, and if we wait long enough with no
progress, autoremovals will implement (3) for us.

    smcv