ustream-ssl ABI_VERSION usage

Daniel Golle daniel at
Tue Feb 13 10:02:27 PST 2024

On 13 February 2024 17:39:29 UTC, Paul Spooren <mail at> wrote:
>> On Feb 12, 2024, at 14:30, Petr Štetiar <ynezz at> wrote:
>> Jo-Philipp Wich <jo at> [2024-02-12 14:09:27]:
>> Hi,
>>> Ideally all packages specifying an ABI version should ship versioned .so files
>>> as well.
>> I would like to point out, that ustream-ssl is dynamically loaded library[1], so we
>> would need to pass that ABI information somehow to the clients, so they would
>> be able to load correct/compatible version of dynlib, not exactly trivial.
>> 1.
>Thank you both for the clarification. I thought that if opkg just isn’t smart enough to figure ABI versions I cleanly solve it via apk, however if we really want to handle parallel installations I’ll teach apk some new tricks.

Updates to libubox or other basic libs used by a lot of packages are the prime example. Having the ABIversion appended to the package name like we do for opkg nicely solves the problem, as in that way libubox12 can be installed in parallel with libubox14.
Not having that option would make selectively updating a system impossible, and imho thats bad because esp. on remote boxes l may not want to update everything just in order to update, lets say, umdns, which may be built against a newer version of libubox than what I'm running now and hence depends on that. When running on a space constraint box with overlayfs updating everything isn't even an option in practise due to jffs2 being to small to fit everything and things in squashfs rom cannot be replaced.

So loosing that (by turning around the provided vs. provider logic as Ariadne was suggesting to not need strippable ABIVersion info added) is really not a good option for OpenWrt I believe.


More information about the openwrt-devel mailing list