On Fri, Dec 21, 2018 at 03:46:29PM +0100, Guillem Jover wrote: > I just noticed the other day that the shared libraries generated from > this source package conflict with all previous SONAME instances. This > is quite problematic because it does not allow coinstallability of > different SONAMEs, which makes upgrades and transitions harder, as it > needs all packages to be installed in block, and to have been rebuilt > against the latest version. That might even make rebuilding > reverse-dependencies impossible, if some of the build-depends still > links against an older version.
Yes, I know. It's something I've been thinking about, without having a clear solution. > I see that the ancillary data files are stored under an unversioned > directory. Depending on whether these can and do change every time a > SOVERSION is bumped, the solutions would be either to split them into > (say) a new libmovit-data binary package, or to keep them in the > shared library package but under a version pathname such as f.ex. > «/usr/share/movitN/» for libmovit.so.N. The first solution won't fly; the shaders are part of the source code and not version-independent. Having /usr/share/movitN may work, but would require patching. Also note that this path is built into every binary depending on libmovit; it is not part of the .so (it comes from the pkg-config file). Longer-term, it would probably be nice to just build the shaders into the .so, with loose files just used for development. But that requires changes upstream, which I doubt we'll be doing before buster freeze -- not the least because it would likely require yet another ABI (or possibly even API) break. /* Steinar */ -- Homepage: https://www.sesse.net/
