3 ms·
The problem is actually: nobody adhering to semantic versioning. Hence the reason why there is a separate API/ABI level embedded into a shared object file, whi
by cookiengineer 2y ago
The problem is actually: nobody adhering to semantic versioning.
Hence the reason why there is a separate API/ABI level embedded into a shared object file, which is pretty much always completely different from the library's package version because they broke compatibility so often.
Additionally there's lots of libraries that break their symbols and hash tables on every subminor update. (Usually when they use LLVM, but I'm not saying it's LLVM's fault)
For example, harfbuzz and libicu are a regular offender of this, meaning they fuck up every downstream project because the method signatures contain a randomized chunk which changes on every single subminor version.
- braiamp 2y agolibicu is deliberately doing this because one of its purpose is to offer Unicode ordering. If consumers try the new ordering on non-rebuild objects, it could lead to data loss. That's what happened with glibc 2.28. [0] If postgres prefers explicit library versions to prevent data corruption, then icu is doing things correctly and making sure that downstream consumers don't shoot themselves in the foot. [0]: https://wiki.postgresql.org/wiki/Locale_data_changes https://wiki.postgresql.org/wiki/Locale_data_changes
- cookiengineer 2y agoHonestly, the more I was researching about what happened in that glibc version update, the more I thought "self inflicted". If you're using NULL terminated strings everywhere, and not UTF8/16, it's your own fault for doing so. Especially if you are building a database which should always contain a length of bytes or at least a CRC check before each entry's contents in its serialized file format to prevent exactly this from happening. (Let alone the question why is there no schema version that should have prevented this from happening in the first place)