https://bugzilla.redhat.com/show_bug.cgi?id=1910504
c...@musicinmybrain.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |needinfo?(timothee.floure@p
| |osteo.net)
--- Comment #9 from c...@musicinmybrain.net ---
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@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
