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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
