https://bugzilla.redhat.com/show_bug.cgi?id=1552767 --- Comment #4 from Rémi Verschelde <rverschelde@xxxxxxxxx> --- (In reply to Neal Gompa from comment #3) > Spec review notes: > > > %if 0%{?mageia} > > BuildRequires: appstream-util > > %else > > BuildRequires: libappstream-glib > > %endif > > This could be simplified to "BuildRequires: %{_bindir}/appstream-util" > > "dnf install /usr/bin/appstream-util" works on both Fedora and Mageia, so I > would think this should work in your spec. Sure, will do. > > # Git commit slightly newer than 2.87 > > # Can be unbundled if bullet 2.88+ is available > > Provides: bundled(bullet) = 2.87 > > If you know the Git commit, could you put that in the Provides versioning? > > Something like the following: > > Provides: bundled(bullet) = 2.87+git<commitdate>.<shorthash> Is the `+git<commitdate>.<shorthash>` standard enough? I wouldn't want scripts relying on parsing `bundled()` provides to break due to invalid NEVR expressions. How about simply specifying the commit (d05ad4b821ba867dfd01f1e5f22c4d9d1bda6869) in a comment instead? > > # Has some modifications for IPv6 support, upstream enet is unresponsive > > # Should not be unbundled. > > Provides: bundled(enet) = 1.3.13 > > I checked into this, it seems like upstream seems to want a mailing list > discussion first[1]? I'm not entirely sure what this means, but it'd be nice > if IPv6 support was in upstream enet (there are three pull requests for > it...) > > [1]: https://github.com/lsalzman/enet/issues/78 We had very lengthy discussions before deciding to vendor and modify enet [0]. The upstream maintainer is very uncooperative (and now, completely inactive), so all projects using enet have ended up forking it for their own usage. There is as of yet no "main" fork to use as upstream, and we eventually wrote our own Godot socket interface to enet, which allows for a much better integration than if we were using the pristine code. So currently unbundling enet is not possible, and not desired. [0]: https://github.com/godotengine/godot/issues/6992 > > # Upstream commit from 2016, newer than 1.0.0.27 which is last tag > > # Could be unbundled if packaged. > > # Godot upstream will soon deprecate this "libsimplewebm" module. > > Provides: bundled(libwebm) > > As you're an upstream developer, I would suggest that libmatroska would be a > better alternative to libwebm (libmatroska can parse webm containers too, > since they are a subset of mkv). But if you're deprecating it... We're going to replace most audio and video plugins (apart from vorbis) by pluggable libraries using the GDNative interface, so that all users can simply pick the plugins they need without having to bundle all the world. > > # Could be unbundled if packaged. > > Provides: bundled(nanosvg) > > If this[2] is the nanosvg in question, I can see why it's bundled instead of > packaged. > > Could you indicate what commit is packaged in nanosvg? You can do something > like the following: > > Provides: bundled(nanosvg) = 0-0.git<commitdate>.<shorthash> > > [2]: https://github.com/memononen/nanosvg That's this nanosvg yeah, so far it's not package in distros that I know of. I haven't actually looked into packaging it yet, but it's a header-only library meant to be vendored by design. The bundled commit is 9a74da4db5ac74083e444010d75114658581b9c7. Same question as above regarding putting it as the bundled() version, can we consider that format standard? The Bundled Software policy [1] is not really explicit. [1]: https://fedoraproject.org/wiki/Bundled_Software_policy > > # Could be unbundled if packaged. > > Provides: bundled(squish) = 1.15 > > Is there any reason it couldn't be packaged? It looks like libsquish is > fairly active and releases often enough. Not that I know of, just needs someone to package it :) As long as Godot is the only user of this dependency, and we already provided bundled sources, I have little incentive to package it myself. But if it were, it's already easy to unbundle with the `builtin_squish=no` argument. The Bundled Software policy [1] doesn't explicitly require packaging thirdparty libraries to unbundle them, but only to use those libraries which are already available. Still, I'm a packager and like clean things, so I might end up packaging libsquish and thus unbundling it somewhere down the road. > > # Can't be unbundled out-of-the-box as it uses experimental APIs available > > # only to static linking. They're not critical features though and could > > # maybe be patched away to link against a shared zstd. > Provides: bundled(zstd) = 1.3.3 > > Have you talked to upstream[3] about stabilizing the APIs used by Godot so > that it can use a dynamically linked libzstd? > > [3]: https://github.com/facebook/zstd No, it's actually a Godot bug to be using experimental APIs in the first place (just opened [2] about it). The contributor who integrated zstd likely did not pay attention to this (those APIs are available when linking statically), I found out that it doesn't build against system shared libraries quite recently. AFAIK there's no reason that the stable APIs wouldn't suffice. [2]: https://github.com/godotengine/godot/issues/17374 -- 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
