From the upstream commit message which added the helper¹:
This is based on the existing gnome-keyring helper, but instead of
libgnome-keyring (which was specific to GNOME and is deprecated), it
uses libsecret which can support other implementations of XDG Secret
Service API.
¹ 87d1353 (contrib: add credential helper for libsecret, 2016-10-09)
We can avoid pulling in libgnome-keyring for git-core installs.
Presumably, those who want a minimal git install won't miss a
credentials helper which is only useful with a graphical desktop.
It is also worth noting that libgnome-keyring is deprecated in favor of
libsecret. A credential helper based on libsecret is included in git
2.11.0 but is not shipped in our packages (yet).
Nothing in git-core requires rsync. Upstream, only git-archimport.perl
still requires rsync, which we have not provided since 3f0dc97 (Drop
git-arch on fedora >= 16, 2011-07-26).
Building on EL was unintentionally broken by 58fa169 (Set LDFLAGS for
hardened builds (#1289728), 2016-04-11).
Thanks to Dimitry Andric for reporting this issue.
This form handles changing package names better. If a module is moved
into or out of core perl, for example, the requirement can still be
found if it uses perl(MOD::NAME).
This was brought up in 1337137.
I updated my vim spec file plugin which improves %changelog generation
and didn't notice that my 'spec_chglog_format' config (which included a
trailing '-') caused a duplicate '-'.
Many years ago, the GPG signature file was included in the source list¹.
A compromise at kernel.org caused the tarballs to move to googlecode.com
for a number of releases and the signatures were not provided in an
easily downloaded format². When the source location was moved back to
kernel.org, the signature file had already been removed from the spec
file and was not re-added³.
There is an effort underway to make GPG signature verification a
requirement when upstream provides signatures⁴. Regardless of whether
this becomes a requirement in the packaging guidelines, verification of
upstream signatures makes good sense. It also makes the process easier
for git package maintainers, who are (or should be ;) doing this
manually for each upstream git release.
While adding the signatures to the source list, all non-upstream source
files were moved to Source10 and above. This should make it easier to
add new upstream source files in the future, avoiding the need for
tedious (and error-prone) renumbering of existing sources.
Remove the unused entry for Patch14 also.
¹ ea3f253 Include gpg signature for tarball in SRPM (2011-08-26)
² c57f383 Update to 1.7.9.1 (2012-02-15)
³ b741f45 Change source URLs, as googlecode doesn't have up-to-date
tarballs (2014-06-10)
⁴ https://fedorahosted.org/fpc/ticket/610https://fedoraproject.org/wiki/PackagingDrafts:GPGSignatureshttps://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2TBK4LLNRH73QJQSXWFPCQYHGTSJ3C7P/
Using https URL's for source files provides a little more security for
those downloading the code. Packagers, of course, should be verifying
the GPG signature files before pushing new releases to Fedora's source
cache¹.
While we're changing the source URL's, we might as well use the smaller
tar.xz files which upstream provides. (This requires minor adjustments
to the unpacking of prebuilt html and man tarballs; tar on el5 does not
know how to automatically filter via xz.)
¹ Replace .xz with .sign for the signatures, which are made against the
uncompressed tarballs.
Workaround missing git subtree documentation in prebuilt docs, dropping
a redundant listing of Documentation/docbook-xsl.css,
Only add git-cvsserver binary once if the core dir matches the
bin dir as it does on el5.
Signed-off-by: Konrad Scherer <Konrad.Scherer@windriver.com>
Using pkg-config for the bash-completion path isn't an option on older
EL systems. To allow rebuilding of current git on those systems, the
bash-completion pkg-config bits are conditionalized similar to other
areas where Fedora and older EL differ.
