[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)?