[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-devel-games@lists.debian.org, libsdl1.2@packages.debian.org

As previously mentioned on -devel, I would like src:sdl12-compat to
take over the libsdl1.2-dev and libsdl1.2debian binary package names
from src:libsdl1.2 during the trixie cycle. This mirrors a transition
that already took place in several other distributions such as Fedora
and Arch.

This is a "soft" transition and does not involve a 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 sdl-config script, different implementation internally), so it's
more like an unusually intrusive minor-version release. I'm opening this
bug for tracking and to coordinate uploading the new version to unstable
at a time that will not disrupt transitions, rather than because any
explicit release team action is needed.

A version with the proposed changes is on its way into experimental,
versioned as sdl12-compat=1.2.64-4+exp1. For a preview of the proposed
changes, users can manually install libsdl12-compat-{shim,dev} from
bookworm, trixie or unstable.

Even after this transition, I consider it to be a (non-RC) bug for
packages to have dependencies on the SDL 1.2 API/ABI. I did a MBF for
that bug, and ideally they would all be ported to SDL 2; but moving to
sdl12-compat reduces the impact of having packages in Debian that have
not been ported.

Having briefly played the majority of the affected games, I suspect that
the value of many of these packages doesn't really justify the QA burden
of keeping them in Debian, but for the purposes of this transition I've
been giving them the benefit of the doubt and assuming that every package
is significant, unless it has obvious issues. (I did ask the ftp team
to remove zsnes and dgen, two non-free i386-only games console emulators
with portable alternatives available in main.)

Risks (build-time)
==================

Dependent source packages do not need to be rebuilt, but if rebuilt for
an unrelated reason, the new libsdl1.2-dev might cause them to FTBFS. I
have done test rebuilds of all dependent packages on a porterbox and
opened bugs for the minority that failed, mostly because they made
assumptions about libsdl1.2-dev that are no longer true:

- https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-sdl-maintainers%40lists.alioth.debian.org&tag=ftbfs-libsdl1.2-compat-dev
- I sent a patch to #1039479 in xine-lib-1.2, which I will raise to RC
  if it's still open when we are ready to proceed
- I fixed #1039575 in powermanga and #1039581 in fenix via team uploads
  into unstable
- the rest have been worked around via sdl12-compat changes in
  trixie/unstable and therefore will not need to be RC

Risks (runtime)
===============

Dependent binary packages might regress after the shared library has
been upgraded. I did some brief testing on the majority of remaining
SDL 1.2 games in bookworm, and most of the regressions that I reported
were promptly fixed or worked around by upstream in sdl12-compat (most
but not all of these fixes made it into bookworm, and all are in unstable
as of 1.2.64-4). The remaining known runtime regressions are:

- https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sdl12-compat
- #1038738 in asc
- #1038741 in bumprace
- https://github.com/libsdl-org/sdl12-compat/issues/301 in fuse-emulator

I think those regressions are, while unfortunate, an acceptable price to
pay for replacing an unmaintained library with a somewhat maintained one.

In general I have not attempted to test non-game SDL-1.2-dependent
packages (mostly emulators and music production software), because
learning how to use them would be more time-consuming than it is for
a typical game, and some of them have non-trivial dependencies that I
do not have (emulators might need non-free ROMs, and some of the music
production software appears to need a manually-configured JACK daemon).

As part of my MBF for dependencies on SDL 1.2, I asked maintainers to
test their packages with sdl12-compat, and the responses so far have been
mostly positive (the fuse-emulator issue linked above was the only new
regression report so far).

    smcv


Reply to: