Package: release.debian.org Severity: normal User: release.debian....@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)