[Bug 882617] Review Request: jsoncpp - An implementation of a JSON reader and writer in C++

[bugzilla at redhat.com]

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=882617

Michael Schwendt <mschwendt at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|nobody at fedoraproject.org    |mschwendt at gmail.com
              Flags|                            |fedora-review+

--- Comment #16 from Michael Schwendt <mschwendt at gmail.com> ---
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