[MIR] libjsoncpp
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| libjsoncpp (Ubuntu) |
Won't Fix
|
Undecided
|
Maarten Lankhorst | ||
Bug Description
Availability:
Builds on all architectures supported by ubuntu, including armel.
Rationale:
This package is already used in main, shipped with llvm-toolchain. Earlier versions of llvm-toolchain used the included copy, more recent llvm-toolchain uses the libjsoncpp shipped with ubuntu.
Security:
I couldn't find any security issues with libjsoncpp, but because llvm-toolchain already used it including it separately wouldn't really increase the attack vector.
Quality assurance:
No open bugs in ubuntu or debian.
UI standards: (generally only for user-facing applications)
n/a
Dependencies:
Build-depends on debhelper, scons, python and doxygen which are in main. Binary package only depends on gcc and glibc.
Standards compliance:
Looks like it complies, and lintian doesn't complain.
Maintenance:
It's not likely a json parser will need much maintainance. Upstream has seen very few commits since rc2, mostly small build fixes.
Background information:
Used by llvm-toolchain-3.3, but a copy included in the source was used by earlier versions of llvm. Debian fixed this for llvm-toolchain-3.2, but that patch is not merged yet in ubuntu.
| description: | updated |
| Adam Conrad (adconrad) wrote | #1 |
| Changed in libjsoncpp (Ubuntu): | |
| status: | New → Won't Fix |
For now, we'll revert to using the static copy, I think. Rationale in the LLVM changelog:
llvm-toolchain-3.3 (1:3.3-5ubuntu4) saucy; urgency=low
.
* Revert to using the static copy of libjsoncpp, since the shared
library lacks sane versioning, and this is only a few thousand
lines of cargo-culted code from a reasonably stagnant upstream.