Open dkwo opened 1 year ago
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)?
Currently, xbps-src looks at
depends
andcommon/shlibs
to generaterun_depends
.This way, for example,
libinput
run_depends
oneudev-libudev
andshlib-requires
libudev.so.1
. This makes it impossible for an alternative provider oflibudev.so.1
likelibudev-zero
to replaceeudev-libudev
(at least withconflicts
set, which should be).Would it be possible to move the logic to
xbps
, namely a package hasdepends
andshlib_requires
, andxbps
takes care to satisfy these (notxbps-src
), such that one could choose which provider of a soname to use (with some priority/default choice)?