RFD: removing git.spec.in (Re: git 2.8.0 tarball rpmbuild error)

It is likely that I'll cut 2.8.1 with only the attached patch

    Message-ID: [off-list ref]
    aka $gmane/290510

and I'll explicitly mark that this maintenance release is ignorable
by people other than those who build their own RPM packages from my
tree.

I think by now it is very clear that nobody active in the Git
development community tests RPM binaries built with git.spec.in we
have in our tree.  I suspect RPM based distros are using their own
RPM build recipe without paying any attention to what we have in our
tree, and that is why no packager from RPM land gave any bug report
and correction before the release happened.

I'd propose that during the cycle for the next feature release, we'd
remove git.spec.in and stop pretending as if we support RPM packaging.

If a group of people feel strongly against the removal, they are
welcome to form a volunteer group and promise to be responsible for
regularly testing the tip of 'next' so that a breakage like this one
will never slip to the 'master' branch.

Unless we see such a promise from dedicated group of people (whose
size does not have to be more than 1), I think it is more harmful
for us to pretend that we support RPM packaging out of our tree than
being honest about it and removing the (pretense of) support.

Discuss.

Thanks.

-- >8 --
Subject: [PATCH] git.spec.in: use README.md, not README
From: Matthieu Moy <redacted>

The file was renamed in 4ad21f5 (README: use markdown syntax,
2016-02-25), but that commit forgot to update git.spec.in.

Reported-by: Ron Isaacson <redacted>
Signed-off-by: Matthieu Moy <redacted>
---
 git.spec.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git.spec.in b/git.spec.in
index d61d537..bfd1cfb 100644
--- a/git.spec.in
+++ b/git.spec.in

@@ -146,7 +146,7 @@ rm -rf $RPM_BUILD_ROOT
 %files -f bin-man-doc-files
 %defattr(-,root,root)
 %{_datadir}/git-core/
-%doc README COPYING Documentation/*.txt
+%doc README.md COPYING Documentation/*.txt
 %{!?_without_docs: %doc Documentation/*.html Documentation/howto}
 %{!?_without_docs: %doc Documentation/technical}
 %{_sysconfdir}/bash_completion.d

-- 
2.7.2.334.g35ed2ae.dirty

On za, 2016-04-02 at 20:41 -0700, Junio C Hamano wrote:

I think by now it is very clear that nobody active in the Git
development community tests RPM binaries built with git.spec.in we
have in our tree. I suspect RPM based distros are using their own
RPM build recipe without paying any attention to what we have in our
tree, and that is why no packager from RPM land gave any bug report
and correction before the release happened.

Fedora, RHEL, CentOS, OpenSUSE and Mageia all use their own specfiles
and local patches. I do test and distribute RPM packages based on the
next branch, but use fedora's packaging to do so (which incidentally
also broke and I had to work around this change, but I completely
forgot about git.spec.in).

I'd propose that during the cycle for the next feature release, we'd
remove git.spec.in and stop pretending as if we support RPM
packaging.

I would be in favor of that. In general, I find it much better to use a
distro's packaging and simply transplanting a tarball into it. That
keeps the difference with what the distro provides minimal.

-- 
Dennis Kaarsemaker
www.kaarsemaker.net