https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639
--- Comment #7 from Andrea Musuruane <musur...@gmail.com> ---
(In reply to Ben Rosser from comment #6)
> > Isn't it possible to patch sources? Please remember that RPM Fusion
> > builders will > need to download these data every time you request a build.
>
> > Isn't it feasible to ship git submodules in the following way?
> > https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Submodules
>
> Well, there are 5 submodules, and they don't really have release tags that
> are in sync with the main repository. I certainly could include them all as
> separate Source: archives, but that seemed tedious, and since I needed the
> .git metadata anyway... but you're right that it's a lot of data to have to
> carry for little gain.
If it isn't feasible, it's OK to rebuild a tarball.
> I guess I could write a script that generates the right %commitX lines for
> the submodules and writes the output of "git describe --tags --abbrev=8
> --long" to a patch. Then at build time the patch is used to get the right
> version information.
>
> Does this approach seem like a reasonable solution?
I think a simple patch to be independent of git data is enough.
The output of "git describe ..." can be placed in the spec file as a variable.
> > And this one too:
> > Provides: bundled(protobuf)
>
> I can check again, but the last time I tried to figure this out it was not
> really possible to figure out which version of protobuf was actually bundled
> (hence my comment in the spec). The version number didn't appear to be in
> any obvious place in the sources. The revision history for the bundled
> libraries isn't ideal either, because at some point 5 years ago they were
> moved from elsewhere in the project into their current directory:
> https://github.com/DFHack/dfhack/commits/master/depends/protobuf/google
>
> The FPC recently ruled that, if it's not possible to determine the version
> number, it is not needed in a bundled provides. See this ticket:
> https://pagure.io/packaging-committee/issue/696. So, that's the approach I
> took.
It can be "the oldest version that seems reasonable as the reason we're doing
this is to tell when a library contains issues that have been fixed in newer
upstream versions".
The following one seems to be the commit that included protobuf for the first
time:
https://github.com/DFHack/dfhack/commit/494a4202dfbede6fa3a9069334458fe7c08dd9d4
Version is in "library/depends/protobuf/google/protobuf/stubs/common.h":
// The current version, represented as a single integer to make comparison
// easier: major * 10^6 + minor * 10^3 + micro
#define GOOGLE_PROTOBUF_VERSION 2004001
i.e. version=2.4.1.
Protobuf files were later moved -as you noted- in this commit:
https://github.com/DFHack/dfhack/commit/eb4757043b12764f20c6bd1a6edc12201f74b2ce#diff-5c3353c6afb85d60c93ec649d1f426a0
Today "common.h" can be found at:
https://github.com/DFHack/dfhack/blob/master/depends/protobuf/google/protobuf/stubs/common.h
Version there is still the same.
So I assume you can specify 2.4.1.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
