Oops, I forgot the title :$

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".

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.