https://bugzilla.redhat.com/show_bug.cgi?id=1552767
--- Comment #5 from Neal Gompa <ngompa13(a)gmail.com> ---
(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