Am 29.03.2017 um 08:56 schrieb Chris Cannam: That's a stupid thing to do for a stable relase of an application, IMHO. How does the SV project expect distribution package maintainers to package the application if it depends on unreleased versions of other software? Chris

Hello. Sad to read that. Will use the Gnu/Debian jessie 2.4.1 package, waiting for stretch to be stable to have the 2.5 version. I do not like to mess around with «stable». Anyhow, nice software, really fun to work with. Learn a lot of things thanks to it. Keep up the good work ! All the best. Le Sat, 1 Apr 2017 14:06:59 -0400, Bernardo Barros <bernardo.barros(a)nyu.edu> a écrit :

On Sat, 1 Apr 2017 14:49:41 -1000, david wrote: That's a good one! Try to build something as a snap that needs access of something outside of the snap ecosystem, e.g. if jackd should be needed. Good luck! I've tested it ;). IIRC you could use some "insecure" developer mode, to get access to everything outside the "container", but snappy and all the other alternatives are unlikely something that improves Linux real-time audio. Regards, Ralf

On 4/1/17 8:51 PM, Christopher Arndt wrote: Well, developers know better. They have their reasons, and I have no intent not to trust them and instead listen to a third-party ranfom packager that has no in-depth knowledge of either projects. It's quite different from a random git package from aur... The developers made this decision, they need this code. Their judgment is certainly more reliable than any one putting together a "distro". The "problem" starts when you want to fit the world in this packaging madness. Just include the code in the source and stop following meaningless rules... geez

On 4/2/17 8:09 AM, Christopher Arndt wrote: So you probably know more about your projects than me or someone packaging it. Well, this kind of problems never happens with other platforms where this kind of problem does not make sense. Packaging in gnu/linux is not bad but it's not a perfect business, it has its downsides too. not really

On 4/2/17 1:34 PM, Ralf Mardorf wrote: What if that's the only way? "Program in a way that it doesn't the git version"(?) It don't think it's a wise suggestion either without looking for the reasons they did it.

On 4/2/17 1:55 PM, Hermann Meyer wrote: Yes, I would suggest that. And if the original dependency changes too much until next release and you can't use it anymore for some strange reason, you will have to fork and adopt it.

On 4/2/17 1:58 PM, Ralf Mardorf wrote: What happened to `universal snaps`? It's not a bad idea.

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

Just to follow up on this thread about Sonic Visualiser's dependency on an unreleased version of capnproto: version 0.6 of capnproto came out today, and should work fine with SV. Chris