Question regarding Trixie and SFML

[Simon McVittie]

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-devel at 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 
libcsfml at packages.debian.org or a bug report, and/or the games team's 
discussion list debian-devel-games at 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