Bug#815036: transition: msgpack-c

[James McCoy <jamessan@debian.org>]

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

Hi,

I'd like to start discussion of a msgpack-c (formerly msgpack)
transition.

msgpack-c 1.4.0-2 is in experimental and I'm ready to start trying to
get it into unstable & testing.  I don't know of any outstanding issues
other than it tickling a possible G++6 bug[0], but there's a possible
workaround already being looked at upstream[1].

[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853
[1]: https://github.com/redboltz/msgpack-c/commit/d1a9ddf80307c7fd8aa5bb060792523cf3e50482

Although there isn't an ABI bump, the 1.4.0 implements the new version
of the msgpack format and has some related API changes.  The old
libmsgpackc2 doesn't understand the new msgpack format, so packages
built against the new library won't run properly if they try to use some
of the newer types.

The libmsgpack3 packge is no longer relevant as the C++ interface is now
header-only.

I've done some test rebuilds of the reverse depends and here's the
breakdown:

FTBFS:

* webdis:
  + #811343 filed with patch
* tmate:
  + New upstream version is needed
  + Will file a bug for this
* kumofs:
  + configure script expects the C++ library (libmsgpack) and therefore
    fails
  + Trivial patch to remove that expectation leads to a compile failure
    due to mixing code with C and C++ linkage
  + No upstream activity in 5+ years
  + Debian maintainer MIA
* libdata-messagepack-stream-perl:
  + This likely needs a newer version of libdata-messagepack-perl, which
    hasn't been uploaded yet
  + Needs to be adapted to new msgpack-c API.  I have some patches I can
    send in that regard.

Good:

* groonga

I'll update this as I file bugs against the FTBFS packages, but I wanted
to get on the radar and see what feedback the team had.

I'm not quite sure about the Ben file, but I think it should be
sufficient.  From what I see, most current packages ended up getting
dependencies on libmsgpack3 so seeing them switch to libmsgpackc2 should
be good enough.  I don't think enforcing a minimum version of the
libmsgpackc2 dependency is accurate, since that depends on what part of
the API is being used.

Although it's most likely that anything build depending on
libmsgpack-dev has *some* binary package that will get a dependency on
libmsgpackc2 >= 1.0.0, not necessarily all of their binary packages
will.  For example, groonga's groonga-bin package has Depends
libmsgpackc2 (>= 0.5.1) after a rebuild but groonga-plugin-suggest gets
libmsgpackc2 (>= 1.0.0).

Cheers,
James

Ben file:

title = "msgpack-c";
is_affected = .build-depends ~ "libmsgpack-dev"
is_good = .depends ~ "libmsgpackc2";
is_bad = .depends ~ "libmsgpack3"


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)