[LAU] Sonic Visualiser 3.0 released

[Chris Cannam]

A few different things came up in this thread, not all of which are very
on-topic for LAU. I'll reply to the batch in one go, but if you want to
talk further about developer/packager specifics, perhaps take it
off-list or to LAD.

 Q. How would I (an end-user) build this SV release?

 A. You'll need a git master checkout of capnproto. The exact revision
 doesn't matter much, as the master is stable enough that the capnproto
 developers have been using it in production for some time. If you want
 a specific revision id, try 86ce27924cea which is the version used in
 the existing Linux build for SV 3.0.2. It's not that much different
 from handling any other library dependency your distro happens not to
 have yet. Yes it's a bit of a pain, yes I somehow forgot to document
 it, and I am sorry about that.

(Of course SV also has a lot of other library dependencies; it's never
been all that simple to build. And version 3 needs a fairly modern C++
compiler, so there may be problems with old distributions anyway.)

 Q. How does the SV project expect distribution package maintainers to
 package the application?

 A. Strange question this one. The SV project doesn't expect anything of
 anyone. I make (currently) four different platform builds of every
 release to try to get the application to as many potential users as
 possible, and if it's also available through distro packages then
 that's a bonus too. If there's a problem packaging it, and a maintainer
 asks about something that needs fixing, then I'd love to help. If it
 involves a solution more practical than, effectively, "write a
 different application" then all the better. I do recall that
 maintainers have also had problems in the past with applications doing
 as Ardour does and bundling specific revisions of upstream libraries in
 the release tarball.

 Q. Can't an application be packaged with a static-compiled copy of the
 required library?

 A. That would seem like a good solution to me -- it's what I do for the
 existing binary packages of SV -- but I'm not a package maintainer.
 There may be rules against it.

 Q. Isn't it really bad practice to depend on an unreleased version in
 the first place?

 A. Yes and no. In this case the upstream repo is pretty stable. I'm no
 more concerned about a capnp update breaking the build than I am about
 a new release of any other dependent library doing the same. When you
 run a configure script, you're getting only the most superficial
 reassurance that the library you're building against is the one the
 developer expected. It would be nice to pin these things properly, but
 as it stands the release tarball is closer to being "the code that
 happened to be in the SV repo when the release builds were made" than
 it is to a reproducible recipe for making such a build. The present
 situation just surfaces the reality of that.

What I should absolutely have done is identify a specific revision (i.e.
86ce27924cea) as having been tested.

 Q. Why have this dependency in the first place?

 A. This software was useful and appropriate, it makes SV a better
 application, and the APIs that SV uses have been present in its stable
 recommended interface for over a year. I would like to see (and have
 asked for) an upstream release, but I don't have any control over those
 schedules.

 Q. Could you have provided a multi-distro installer via e.g. Snap?

 A. I did look into this, without much success -- I'd love to hear of
 any better experiences from other developers. Canonical's Snap is only
 ever likely to be supported on Ubuntu, and I already provide an Ubuntu
 package anyway. Flatpak from Red Hat looks more promising technology,
 but it also has limited support (presumably as long as Snap exists,
 Flatpak will never be properly supported on Ubuntu) and it only works
 on the very newest distro releases. AppImage is conceptually simpler
 but it certainly didn't seem simple to make a true cross-distro
 package, and the AppImage example package I tried wouldn't run on my
 own (Arch Linux) system.


Chris