Embed Notice

one key takeway i had from this soname / abi != package-version / api is that adding fields to structures shouldn’t be a thing to worry about that much, removing them yes, adding, reordering, etc, no

libraries shouldn’t keep their data “obscured” behind a malloc-d pointer just for the sake of binary compatibility. there is other reasons for opaque pointers, but more often than not, a library will be better by letting users choose where to allocate data, be it on the stack or on the heap or statically or so on

and if you worry about people accessing fields they shouldn’t, c23 provides [[deprecated]], meaning you can do:

and mark struct members as such

distros should have mechanism to easily trigger rebuilds on soname changes, as well as mechanisms to keep the old soname around as long as there’s packages linked to it

the fact that some distros don’t, is not a limitation of the system, but an implementation failure