Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=882617 Michael Schwendt <mschwendt@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|nobody@xxxxxxxxxxxxxxxxx |mschwendt@xxxxxxxxx Flags| |fedora-review+ --- Comment #16 from Michael Schwendt <mschwendt@xxxxxxxxx> --- Hmmm, with regard to the shared library this is sort of a grey area. We don't have anything in the packaging guidelines that comments on "making up versioned SONAMEs". I can only repeat comment 8 and approve this package with a big fat warning only. You will need to take the full risk and the full responsibility for shipping a libjsoncpp.so.0 that may be incompatible with a future upstream release, other distributions, or even updates of jsoncpp within Fedora. The automatic RPM SONAME dependencies won't help you either within the Fedora package collection. You'll be on your own here, and you'll need to be very careful and check the API/ABI of future updates with the help of tools like diff, rpmsodiff and abi-compliance-checker, for example. If the ABI breaks often, it would be better to use a stricter SONAME version, but with the added penalty that you would need to invent a suitable versioning scheme or rebuild dependencies more often than necessary. As a last resort, you could continue building a shared lib, but with a SONAME that would change [almost] always. It's also less than ideal that upstream has not responded to the ticket and/or forum thread which you've opened. In case of doubts, it might also be an idea to consult the Fedora packaging mailing-list for feedback on this. And, of course, this is an opportunity to team up with the Orthanc packagers and have more people check/co-maintain future jsoncpp updates/upgrades. > Upstream does not provide a soname, so I use 0.0.0. See comment 6. libjsoncpp.so.0 $ eu-readelf -d /usr/lib64/libjsoncpp.so.0.0.0 |grep SO SONAME Library soname: [libjsoncpp.so.0] > # Build the doc > python doxybuild.py Python is only available indirectly because of Scons. There are two minor packaging issues left, which shouldn't block the package, however: * jsoncpp.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/jsoncpp-0.6.0/AUTHORS * jsoncpp-doc : /usr/share/doc/jsoncpp/index.html links a few local files, which are only packaged in the base jsoncpp package %doc dir. E.g. LICENSE, *.txt. Those links give 404 not found, of course. Duplicating those %doc files in the -doc package would be acceptable here, IMO. Making jsoncpp-doc depend on the base package would not be good, because Documentation packages usually should stay independent. > Summary: An implementation of a JSON reader and writer in C++ And last but not least, now that I've had another look at the spec, I'm not a fan of leading articles at the beginning of the "Summary". When those summaries are displayed by Anaconda and package tools, that looks ugly if many of them start with "An, "A, "The". Nowadays most packages drop leading articles, I think. Also, mentioning that this is a library or API might be better. Mentioning that reading and writing is implemented might be too much, because a future version might also offer checking/validating. It's okay if the description expands on such details. Summary: JSON API for C++ Summary: JSON library implemented in C++ Summary: C++ library for reading and writing JSON Up to you, of course. ;) APPROVED -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CRMvoSKLHP&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review