FS#71266 - [sdl2] use soname version provides

Attached to Project: Arch Linux
Opened by Alexandre Bouvier (doskoi) - Wednesday, 16 June 2021, 03:23 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Wednesday, 16 June 2021, 18:44 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Sven-Hendrik Haase (Svenstaro)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Can you add, as recommended in the Arch package guidelines [1], the external shared library `libSDL2-2.0.so` to the provides array?
It will allow pacman to block an update if a soname bump in sdl2 breaks a package depending on sdl2 [2].

$ find-libprovides /var/cache/pacman/pkg/sdl2-2.0.14-1-x86_64.pkg.tar.zst
libSDL2-2.0.so=0-64

[1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_relations
[2] https://bugs.archlinux.org/task/58947
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Wednesday, 16 June 2021, 18:44 GMT
Reason for closing:  Won't implement
Comment by Alexandre Bouvier (doskoi) - Wednesday, 16 June 2021, 03:26 GMT
Oops, I forgot the title :$
Comment by Eli Schwartz (eschwartz) - Wednesday, 16 June 2021, 06:34 GMT
I disagree; the wiki page is wrong (or incomplete) and the DeveloperWiki suffers from being locked to editing and having very *few* people able to edit/improve it, so it lacks perspective, depth, and consensus and generally speaks in absolutes about a very nuanced topic.

The specific problem here is that advice is actually terrible and downright wrong, if like sdl2 there is a version coming before the .so

libSDL2-2.0.so.0.14.0

provides SDL2, version 2.0.14, where the 2.0 is included (twice!) in the library name libSDL2-2.0.so, which you need to add to provides=(), and makepkg will then auto-version it to "0", and the final 14 isn't used by the soname versioning.

> if a soname bump in sdl2 breaks a package depending on sdl2

then all PKGBUILDs would need to be edited to include a different dependency, and the libprovides/libdepends feature of makepkg was useless; you could just add versioned dependencies on sdl2>=... sdl2<...

Given sdl2 is version 2 of sdl and they include that in the library name (again, twice!) with a soname version of "0" my guess is they strongly intend to not break compat until perhaps sdl3?

See https://wiki.libsdl.org/Installation

> We are obsessive about SDL2 having a backwards-compatible ABI.

Wiring up libprovides would be a lot of annoying administrivium that fails to provide value while consuming a fair chunk of time to update dozens of packages in pursuit of bureaucratically following an underspecified rule merely because "it's the rule".
Comment by Sven-Hendrik Haase (Svenstaro) - Wednesday, 16 June 2021, 18:44 GMT
Indeed. I don't think I intend to do this. SDL2 rarely ever breaks compatibility (I don't think it ever has) and besides, we don't really want to create situations where we block on partial updates anyway.

Loading...