Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1123785
Summary: | json-c has API changes without soname bump | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Sandro Mani <manisandro> |
Component: | json-c | Assignee: | Christopher Meng <i> |
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | dtardon, fedora, i, jiri, walters |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-02-17 09:55:06 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Sandro Mani
2014-07-28 09:14:34 UTC
I will forward this to the upstream to tell this problem. And, have you requested a rebuild of postgis to see if it still exists? postgis does not build against the new json-c due to the API changes. I think the first priority is bumping the soname so that all packages with broken dependencies get caught. In particular, for stable releases, the update should get unpushed. Per upstream changelog, function json_tokener_error_desc() should be its replacement. I will modify the Makefile tomorrow to bump the soname. I'm starting the checkup to see how many packages affected, 1 confirm unaffected: zmap. [tinga@fab hhvm]$ readelf -Ws /usr/sbin/zmap | grep json 15: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_new_array 16: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_to_json_string 17: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_new_string 30: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_array_add 33: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_new_object 57: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_new_int 67: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_object_add 92: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_new_double 118: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_new_int64 124: 00000000 0 FUNC GLOBAL DEFAULT UND json_object_put 207: 080708a0 32 OBJECT GLOBAL DEFAULT 24 module_json_file 223: 080600c0 1537 FUNC GLOBAL DEFAULT 13 json_output_file_init 244: 0805fe00 597 FUNC GLOBAL DEFAULT 13 json_output_file_ip 365: 08060060 86 FUNC GLOBAL DEFAULT 13 json_output_file_close In progress... Bumped: json-c-0.12-3.fc22 json-c-0.12-3.fc21 Thank you This could have been avoided by using basic tools, such as rpmsodiff (or abi-compliance-checker), more often than not during version upgrades.
> +# Bump the soname manually.
> +sed -i 's#2:1:0#3:0:0#' Makefile.am
Has this been acknowledged by the upstream developers? If you bump soname versions on your own, that bears several risks.
Bumping soname without upstream acknowledgment seems a very bad idea (what will you do when upstream will really bump soname ?) I really prefer we keep 0.11 for now (at least in Fedora 21). More: this update breaks php-pecl-jsonc (lot of test are now "failed") We already have lot of people crying because of minor behavior change between ext/json (non-free) and pecl/jsonc, introducing some other is juste a very bad idea. My goal is to fork the json-c parser, bundled it in pecl/jsonc (yes !) and adapt it to optimize parser time and fix difference with ext.json But this is a long road and probably not in a very short time. (In reply to Remi Collet from comment #7) > Bumping soname without upstream acknowledgment seems a very bad idea (what > will you do when upstream will really bump soname ?) > > > I really prefer we keep 0.11 for now (at least in Fedora 21). > > > More: this update breaks php-pecl-jsonc (lot of test are now "failed") Is it OK for you to port your code to 0.12? Schedule? > We already have lot of people crying because of minor behavior change > between ext/json (non-free) and pecl/jsonc, introducing some other is > juste a very bad idea. > > My goal is to fork the json-c parser, bundled it in pecl/jsonc (yes !) > and adapt it to optimize parser time and fix difference with ext.json > > But this is a long road and probably not in a very short time. Yes I understand. I just spent 2 hours reading your code. (In reply to Christopher Meng from comment #8) > > More: this update breaks php-pecl-jsonc (lot of test are now "failed") > > Is it OK for you to port your code to 0.12? Schedule? Not planed. External issue appears to be: https://github.com/json-c/json-c/issues/147 All packages should have been fixed. Upstream is still keeping silent on the soname bump, I have no idea. |