[feature request] move shlibs logic to xbps
dkwo opened this issue · comments
Currently, xbps-src looks at depends and common/shlibs to generate run_depends.
This way, for example, libinput run_depends on eudev-libudev and shlib-requires libudev.so.1.
This makes it impossible for an alternative provider of libudev.so.1 like libudev-zero to replace eudev-libudev (at least with conflicts set, which should be).
Would it be possible to move the logic to xbps, namely a package has depends and shlib_requires, and xbps takes care to satisfy these (not xbps-src), such that one could choose which provider of a soname to use (with some priority/default choice)?
Not until the dependency solver is rewritten.
Generally if this is going to change then it will probably become more strict, not less.
We would probably require at least the version of the shared library providing package the target package was build with, instead of recording the first time the given shared library version appeared.
This is because adding symbols to the shared library doesn't break the abi and a package build against a newer version might be using symbols that are not present in previous package version with the same shared library version.
At the moment, you'll have to use provides+replaces like dbus-libs and dbus-elogind-libs do.
When that day comes, would it make sense to switch to a model like Alpine's apk, where you have a file /etc/apk/world with a list of constraints, and the dependency solver recomputes the whole package graph every time you add or delete a package to that file (rather than installing, marking as auto, removing orphans etc with different commands)?