https://bugzilla.redhat.com/show_bug.cgi?id=1552767 --- Comment #5 from Neal Gompa <ngompa13@xxxxxxxxx> --- (In reply to Rémi Verschelde from comment #4) > (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? > You can do that too, if you'd prefer. We don't actually have any tooling for processing bundled() Provides. It's mainly observed by humans when checking for security issues. > > > # 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 > This is reasonable, though someone really should try to revive it properly so forking ad infinitum goes away... > > > # 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. > OK. > > > # 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 > As I said earlier, it's mainly for humans to analyze, so there's no "standard" aside from using a valid RPM version-release. Since nothing is supposed to require bundled() Provides, it should be fine to use that too.. > > > # 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 Good to know. -- 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
