On Fri, 30 May 2025 at 20:15:47 +0200, Marc Haber wrote:
If the libraries are not backwards compatible, you might want to talk
to the Debian Games Team (pkg-games-de...@lists.alioth.debian.org)
whether they plan to package the 3.0 series independently from the 2.x
series in Debian 14/forky.
Better to contact the maintainers of this specific library via
libcs...@packages.debian.org or a bug report, and/or the games team's
discussion list debian-devel-ga...@lists.debian.org, in this case. I've
cc'd the relevant addresses here; please consider dropping the cc to
debian-devel in any replies.
The pkg-games-devel list is high-traffic with lots of autogenerated
messages about all of the team's games, but most of the team probably
don't read that whole list, because most of its traffic is not relevant
to most team members - instead, I suspect most team members are only
subscribed to messages about a few specific games and libraries that
they're interested in.
On Fri, May 30, 2025 at 01:43:25PM -0400, First Name wrote:
The [SFML] 3.0 series is not
available yet in Debian 12, however, when it does come available, I would
want the 2.0 series to still be available due to the lack of backwards
compatibility SFML provides.
Whether to make the new major version completely replace the old one
(like we do for new major versions of OpenSSL) or coexist for a while
(like we do for new major versions of SDL, GTK and Qt) is a decision for
the package's maintainer to make. At the moment the version packaged in
experimental completely replaces SFML 2.x rather than being an
independent package: they both implement libcsfml-dev. (Like OpenSSL,
unlike SDL/GTK/Qt.)
If the upstream developer of this library intended the two different
major versions to be parallel-installable (like SDL, GTK and Qt do),
then they would have needed to choose names for the files of the new
major version that allow them to be installed together:
<https://ometer.com/parallel.html> (which is 20+ years old but is still
good advice). However, it seems they didn't do that: both version 2 and
version 3 have pkg-config modules with names like csfml-audio.pc and
shared libraries with names like libcsfml-audio.so, which means
developers cannot have both version 2 and version 3 installed at the
same time.
Unless this has changed since 3.0.0 rc1, if SFML 3 was packaged
separately, then libcsfml3-dev would need a Conflicts: libcsfml-dev
preventing them from being installed at the same time (like the way
libfltk1.3-dev and libfltk1.4-dev are separate packages, but cannot
both be installed on the same system at the same time).
It is not always completely obvious whether a separate package for a new
major version is a good idea, even when it is technically possible. A
recurring problem that we have in Debian is that upstream projects
release a new major version of a library (like SFML 3), and either
immediately or some time later they stop supporting the old version
(like SFML 2). If the old version is a separate package, the risk is
that the old, unsupported version continues to hang around in Debian for
several years afterwards, taking up QA resources and suffering from bugs
and sometimes security vulnerabilities, because nobody wants to remove
older programs that still use the old version and were never ported to
the new one - but nobody is really maintaining it either, because the
most we can realistically do with a library that is dead upstream is to
fix the most urgent issues to keep it on life-support.
For example we've seen this with GTK 2, SDL 1.2, every previous Qt major
version, libsoup 2.4 and many more. One way to force this not to happen
is to only have the new library (similar to the way OpenSSL 3 completely
replaced earlier OpenSSL versions in Debian), which gives dependent
programs an ultimatum: either they must be updated to the new library,
or they can't be in Debian any more.
smcv
