Raphaël Hertzog writes: > Package: libuhd003 > Version: 3.9.0-1 > Severity: serious > User: de...@kali.org > Usertags: origin-kali > > I just noticed that with uhd 3.9.0 libuhd003 lost the v5 suffix that had > been introduced with 3.8.5-2.1. > > And the changelog has no explanation for this. So to avoid problems > when upgrading from jessie to stretch, this should be fixed again... > > Thank you!
I've got uhd-3.9.1-1 conflicting with gnuradio << 3.7.8-3 and I am considering adding a versioned depends for gnuradio 3.7.8-4 and libgnuradio-osmosdr0.1.4 0.1.4-3 that requires libuhd003 >= 3.9. Will that be enough to avoid problems when upgrading from jessie to stretch? Upstream has been breaking ABI routinely. Another approach would be to patch the soname and soversion for the Debian packaging resulting in a new libuhd3.9 library package. At the moment I am preferring this approach to the v5 suffix approach. But if taking the v5 suffix approach is the recommended way forward, I can certainly do that. But I would like your advice now that you know upstream UHD often breaks ABI without soname/soversion bumps. I think UHD upstream is interested in best practices for library release management, but, like me, needs a bit of education and a plan to move from the current state of release management to something better. Thanks, -Maitland also: peter green writes regarding bug #794878: > It appears the library rename introduced in uhd 3.8.5-2.1 was reverted > in uhd 3.9.0-1. There was no mention of this revert in the changelog. > > Was the revert intentional and if so what was the reasoning behind it? Yes it was intentional. The reasoning is that uhd routinely changes ABI and API between versions. I have been using versioned package dependencies to manage library ABI changes. Since 3.9.0 was another ABI bump from 3.8.5, I went ahead and reverted the library rename. Not mentioning this in the changelog is my mistake and I do feel silly for not doing it. I used dh-acc to check that uhd 3.9.1 was compatible with uhd 3.9.0. Also, upstream has told me that they were beginning to use the abi-compliance-checker tool as well. So with luck better library soname and soversion settings will make it easier to follow normal library package name conventions in the future. Thank you for your interest and attention. Library ABI/API release management and soname/soversion practices are weaknesses of mine, so I am eager to learn. Let me know any comments or advice you have, and I'll pass it along to my upstreams too. When faced with upstream libraries not bumping sonames, how many Debian packages patch to do their own library release management versus simply following upstream's conventions? Thanks, -Maitland
