Thanks for that useful braindump, Jon. Gives me a really good idea of
intent of the lib.
I've been discussing it on IRC - see the attached log. Advice from the
Debian folks I've spoken to is to not ship a static binary build on
the expectation that other packages will be able to build against it
as part of their own binary builds. In summary, that is problematic
because changes to the lib made by mypaint may require those other
packages to perform additional binary uploads. Runtime support
packages for such static blobs only serve to compound the issue. Such
additional uploads are organizationally fiddly, and technically
unnecessary in comparison to the same lib expressed as a dynamic
library package with a declared ABI level reflected in the SONAME.
Given the above, I won't be making libmypaint* packages which contain
only a static .a and runtime support for it.
Given the current ABI instability and lack of docs (and given that I
don't want to be overambitious at first with my packaging!), I
probably won't be making dynamic libmypaint* packages for the 1.1.x
release, and I won't be doing so at first.
On a strategy note, would it be possible for a future release to
support both of the use-cases you identify by building two dynamic
libraries? One for the minimal core, and one depending on it for the
glib+GI+GEGL brew. It's certainly a lot nicer for Linux distributions
to do it that way, which in turn may help the code gain popularity☺.
Apps which require static linkage would still have the option of
bundling, if that's a more normal thing to do on certain platforms.
--
Andrew Chadwick
#debian-mentors Mon 07 Jan 2012 12:10 - 12:39
<achadwick> Is there an established convention for naming runtime support
packages for apps built against a _static-only_ library? Translated strings in
my case. I want to name the static dev package "libmypaint-dev", so should
runtime stuff go in a "libmypaint-data" or "libmypaint-common"?
<achadwick> What's the most unsurprising name? I'm pondering using just
"libmypaint", but that might be confusing because a) upstream intend to support
dynamic libs once the ABI is more stable, and reading closer, b) the usecase
(and ABI) for dynamic is intended to be fuller, by design.
<pabs> best not distribute the library at all until it becomes dynamic
<achadwick> Why?
<OdyX> or ship a -dev package with everything needed to compile it
<OdyX> achadwick: because we don't want packages to incorporate static
libraries components; that's not how Debian is supposed to work.
* dpkg has quit (Quit: buh bye!)
<OdyX> achadwick: a possibility would be to patch the thing to have a
Debian-specific SONAME (see libjim for example) and go through NEW every time
you want a new release.
<achadwick> Yep. I'm intending to ship a -dev package with headers and the .a
in question. (Disclaimer: I'm part of upstream, but I don't work on that bit. I
support the developer-in-question's use cases and intents development against
it.)
<achadwick> *for development
<OdyX> what is the benefit for both Debian and the library upstream developers
to have it in Debian ?
* dpkg ([email protected]) has joined #debian-mentors
<achadwick> Upstream Gimp, Krita, and Blender have expressed interest in using
the engine, and this would be the static linking usecase. It could facilitate
development if they didn't have to bundle it into their source and could just
rely on external provision of headers and a static lib. For the DDs of the
package, the same would hold via build-dependencies.
<achadwick> The libmypaint source (it's a lib for rendering dynamic brush
strokes generated with graphics tablets into pixel buffers) is currently part
of the mypaint source (a python app which builds its own C++ bits against the C
libmypaint, statically; at present)
<pabs> sounds like it would be much more useful for those purposes once the API
and ABI is stabilised
<pabs> good to hear about the convergence though, mypaint brush stuff is great
<OdyX> looks like more dynamic linking + ABI stability evangelism is needed.
<algernon> 2
<achadwick> Dynamic linking will happen, just not by default in this release.
It'll be required for the gir view of the lib in its "full" configuration. That
part, I think, is not yet stable enough.
<achadwick> Noting
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static
- basically we hit the last couple of bullet points.
<OdyX> achadwick: the problem with static linking is that any update of the
library imposes a binNMU of all packages making use of it
<OdyX> and that's anti-distro-ish
* pabs would suggest just shipping a dynamic lib from the start and bump ABI
every time as usual
<OdyX> yeah, same here.
<OdyX> achadwick: I've done just that for jimtcl - libjim and it's not a too
big pain to manage, and has many benefits IMHO.
<pabs> if upstream isn't enabling that yet you can do so and use a
Debian-specific SONAME (append d or debian to it)
* yann_s|AFK is now known as yann_s
* achadwick nods. There's an argument for pushing for a dynamic lib for each of
the two configurations the author wants: (1="minimal", to pixel buffers exposed
by the app via a c-ish surface subclass, 2="full", to that or a reference GEGL
surface, with a GI interface)
<achadwick> I suppose 1. "looks" more static, but presumably it doesn't have to
be.
<achadwick> The insight re reliance on static libs being unpleasant for distros
makes sense. I shall convey :)
* hyperair ([email protected]) has joined #debian-mentors
<pabs> thanks!
_______________________________________________
Mypaint-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/mypaint-discuss
