rubberband devendoring required
Brought to you by:
cannam
Menu
▾
▴
#265 rubberband devendoring required
What was the idea behind undonditionally forcing rubberband in a vendored version upon the users since version 3.2?
This is slightly annoying, as a packager has to manually de-vendor this with a bunch of sed's and exports.
rm -rf rubberband
sed -e '/rubberband/d' \
-e 's/vamp-plugin-sdk \\/vamp-plugin-sdk/' \
-i base.pri
sed -e '/rubberband/d' \
-e 's/PulseAudioIO.h \\/PulseAudioIO.h/' \
-e 's/SystemRecordSource.cpp \\/SystemRecordSource.cpp/' \
-i bq-files.pri
export LIBS="$(pkg-config --libs rubberband) ${LIBS}"
This was an exasperated hack in response to an Ubuntu packaging problem:
https://code.soundsoftware.ac.uk/issues/1853
I agree there are certainly better ways to deal with this - perhaps for 3.3.
Hm, sorry, but this doesn't make any sense!
If Ubuntu has broken packaging of librubberband2, they need to fix that, not you and in turn break your source code for every other distribution!
I suggest, that if you want to provide .deb packages (instead of letting downstream take care of that - always the easier solution) to link them statically all the way (but not force this on everyone else by making it mandatory).
If you want to provide a deb for 16.04 specifically (but non-static), you need to build on that system and provide a repo (this would generally make sense then for all versions of Ubuntu, that don't provide the software yet). A "one-fits-all" approach rarely works out.
This really is an Ubuntu specific issue, that they need to cope with and for higher versions of said OS they will start devendoring as well, as they depend on librubberband2 (https://packages.ubuntu.com/cosmic/sonic-visualiser).
This was specifically about providing a .deb that people who use Ubuntu (any recent-ish version from the last few years) can download, install, and run, in the case where they want to get the current SV version independent of what version is in the distro repositories. This is entirely a response to the way some real users interact with the software - as with every awkward interaction with the real world it would be nice not to have to do it, but as you can see from the download figures, a number of people do make use of it.
In the distant past this build was statically linked, but there were various problems with that as well (and also with maintaining separate static/dynamic build flags) which made the lighter dynamic .deb with dependencies seem preferable. I don't wish to go back to trying to produce a static build, and obviously I am not going to ask Ubuntu packagers to retroactively make their library packaging more consistent.
As I said, I am aware there were better ways to solve this - causing this one library to be statically linked for that build would have been enough. But this was a very late blocker for a release, so I was in a hurry, and this solution came to hand. I'm saying this not to justify it particularly, just to answer your question about how it came to be.
Have de-vendored this library in the current repo, for next release (3.3).
Released in 3.3
Thanks, this fixed it for me! :)
@cannam this can be closed