https://bugzilla.redhat.com/show_bug.cgi?id=1910504 code@xxxxxxxxxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(timothee.floure@p | |osteo.net) --- Comment #9 from code@xxxxxxxxxxxxxxxxxx --- The linked SRPM is built with an old version of the spec file; it does not match the spec URL. ----- It’s not hard to unbundle at least the header-only libraries. For example, for uthash, which was already in Fedora: 1. Per the guidelines for depending on header-only libraries, you need to BR uthash-static in addition to uthash-devel. 2. In %prep, “rm -rf uthash/*” That’s all! Now it uses the system copy. Now there are some problems with uthash 2.x, vs. the bundled 1.x: * libucl uses removed macros utstring_append_len() and utstring_append_c(); this could be easily patched by defining them, if missing, in src/ucl_internal.h * ucl_parser.c uses strtoimax without directly including inttypes.h, which was previously indirectly included from uthash.h; this is also easily patched * ucl_emitter_utils.c uses uthash internals, accessing the pd member directly, but this member no longer exists in 2.x Okay, now it’s getting hard. At this point we could decide that this is more than we are willing to try to patch, and leave the library bundled—not because of the build system, but because of the uthash 2.x incompatibility. In that case, you need to: 1. Drop the BR’s on uthash-devel and uthash-static 2. Write the virtual Provides for the bundled library correctly: instead of Provides: bundled(uthash-devel) it should be # See UTHASH_VERSION in uthash/uthash.h Provides: bundled(uthash) = 1.9.8 3. File an upstream bug report about the incompatibility and link it from the spec file! ----- You really need to try to unbundle at least the other header-only libraries, since it is as easy as removing the bundled copies in %prep (which you are required to do for bundled libraries anyway). That’s pretty much upstream support. They only thing upstream could do to make it easier would be to provide a configure argument. I think the guidelines don’t really give you any wiggle room here. Note that for anything you do not unbundle because upstream does not support using an external/system copy, you are required to publicly contact upstream (e.g. via a GitHub issue) requesting that support. ----- The Python bindings still have a license problem, as they claim to be MIT-licensed but lack a license/copyright statement. I see there is now an upstream bug report about this: https://github.com/vstakhov/libucl/issues/252. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
