4 Apr
2017
4 Apr
'17
12:54 p.m.
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