Two nights ago I compiled a modified version of Calamares. The next morning, when trying to run it, I got:
/usr/bin/calamares: error while loading shared libraries: libkpmcore.so.11: cannot open shared object file: No such file or directory
I see that Manjaro has updated kpmcore to have libkpmcore.so.12.
And here’s my newbie question: what’s the best chance I have to prevent this on my own Calamares package?
Thanks for your help.
If you rely on specific versions, you could include them statically in your build.
However, when your underlying runtime changes, you must expect breakage and you need to recompile your own package.
I’m trying a sane way to do that, but I’m utterly clueless right now.
I don’t recommend that.
You’ll end up with outdated libraries in your build that potentially has security implications.
You can use the checkupdates script before commiting the actual update.
Then check if the package containing your dependency has been updated - thus you can know beforehand and take appropriate action.
Thanks for your points.
Maybe I could bundle inside the package any shared library that has an unstable ABI, and automatically increase the package release when that dependency updates.
So I get the best of both worlds: a pseudo-standalone package, with updated shared libraries.
The package being standalone is important for two reasons. First because it doesn’t need to keep in sync with repositories that don’t depend on me, so the package never breaks and it is also quite portable among Arch Linux variants.
Second, so packages can be updated in a one by one basis. That should simplify the repository building process quite a lot, as we no longer need to care which package should be built first, or hold groups of packages so they play well together.
Nevertheless updating as soon as dependencies are updated doesn’t seem a necessity for Calamares, as it has two releases per month. That should be enough for warranting security.