From: Ian Ward Comfort <icomfort@stanford.edu>
To: Ben Walton <bwalton@artsci.utoronto.ca>, git@vger.kernel.org
Subject: [PATCH] RPM spec: include bash completion support
Date: Fri, 26 Mar 2010 01:39:57 -0700 [thread overview]
Message-ID: <1269592797-18487-1-git-send-email-icomfort@stanford.edu> (raw)
In-Reply-To: <1269569690-sup-4884@pinkfloyd.chass.utoronto.ca>
Include the bash completion routines from the contrib/ directory in our core
RPM, in the de facto standard location.
Signed-off-by: Ian Ward Comfort <icomfort@stanford.edu>
---
On 25 Mar 2010, at 7:19 PM, Ben Walton wrote:
> Excerpts from Junio C Hamano's message of Wed Mar 24 20:41:16 -0400 2010:
>
> > * bw/git-completion-rpmspec (2010-03-20) 1 commit
> > - Add a git-completion rpm subpackage to the spec
> >
> > Shipping bash-completion as part of RPM package; since Todd Zullinger who
> > packages git for Fedora joined the thread, I am hoping that I can defer
> > the direction of the final version to the discussion between Todd and Ben.
>
> I think Todd made a good case for making this part of the core git rpm.
> Ian's patch would be more suited for inclusion in this case. The remaining
> question is whether to stick it in /etc/bash_completion.d or in
> /usr/share/bash_completion.d (the triggers vs direct bit).
/usr/share/bash-completion was the alternative, I believe.
> The closer the core spec file is to the one that distro's use, the better.
> This is a reciprocal benefit, I think.
I agree. After more diligent research (following Todd's tip about the new
upstream), I gather that bash completion works as follows on all of Fedora,
EPEL, Mandriva and Gentoo. The bash-completion package itself:
* Installs a (mostly-)empty /etc/bash_completion.d directory.
* Installs numerous completion modules into /usr/share/bash-completion.
* Defines %triggers for other packages, to symlink its own completion modules
for their binaries from /usr/share/bash-completion to /etc/bash_completion.d
when those packages are installed.
* Induces interactive shells (via one mechanism or another) to source the
contents of /etc/bash_completion.d.
Debian (FWIW) currently installs all completion modules directly into
/etc/bash_completion.d. A promising thread from January 2009 on the upstream
mailing list seemed poised to unify all these distros' treatment, but stalled
after a dozen messages [1].
Unfortunately, nothing in the above clarifies how other packages are expected
to ship their own completion support. Currently, however, the Git packages
(and what other packages I've found with completions) in all these distros --
with the possible exception of Gentoo, which I haven't been able to verify --
install completions directly into /etc/bash_completion.d. This seems natural,
given that the symlink mechanism's current function is to have completions for
all and only installed packages in /etc/bash_completion.d.
I also think Todd's argument is sound, and propose that we ship bash
completions in the core package in /etc/bash_completion.d/git. I don't see
any reason to provide a "--without completion" option, since downstream
packagers will continue to either patch or replace our spec if it doesn't meet
their needs.
[1] http://lists.alioth.debian.org/pipermail/bash-completion-devel/2009-January/000670.html
--
Ian Ward Comfort <icomfort@stanford.edu>
Systems Team Lead, Academic Computing Services, Stanford University
git.spec.in | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index ee74a5e..9533147 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -127,6 +127,9 @@ find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
rm -rf $RPM_BUILD_ROOT%{_mandir}
%endif
+mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/bash_completion.d
+install -m 644 -T contrib/completion/git-completion.bash $RPM_BUILD_ROOT%{_sysconfdir}/bash_completion.d/git
+
%clean
rm -rf $RPM_BUILD_ROOT
@@ -136,6 +139,7 @@ rm -rf $RPM_BUILD_ROOT
%doc README COPYING Documentation/*.txt
%{!?_without_docs: %doc Documentation/*.html Documentation/howto}
%{!?_without_docs: %doc Documentation/technical}
+%{_sysconfdir}/bash_completion.d
%files svn
%defattr(-,root,root)
@@ -192,6 +196,9 @@ rm -rf $RPM_BUILD_ROOT
# No files for you!
%changelog
+* Fri Mar 26 2010 Ian Ward Comfort <icomfort@stanford.edu>
+- Ship bash completion support from contrib/ in the core package.
+
* Sun Jan 31 2010 Junio C Hamano <gitster@pobox.com>
- Do not use %define inside %{!?...} construct.
--
1.7.0.2
next prev parent reply other threads:[~2010-03-26 8:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-25 0:41 What's cooking in git.git (Mar 2010, #06; Wed, 24) Junio C Hamano
2010-03-25 15:11 ` Nguyen Thai Ngoc Duy
2010-03-25 16:27 ` Brandon Casey
2010-03-25 23:11 ` Alex Riesen
2010-03-26 22:53 ` [PATCH 1/2] Allow passing of configuration parameters in the command line Alex Riesen
2010-03-26 22:56 ` [PATCH 2/2] Use strbufs instead of open-coded string manipulation Alex Riesen
2010-03-26 5:47 ` What's cooking in git.git (Mar 2010, #06; Wed, 24) Nguyen Thai Ngoc Duy
2010-03-25 15:16 ` Nguyen Thai Ngoc Duy
2010-03-26 2:19 ` Ben Walton
2010-03-26 8:39 ` Ian Ward Comfort [this message]
2010-03-26 12:10 ` [PATCH] RPM spec: include bash completion support Ben Walton
2010-03-29 18:17 ` Junio C Hamano
2010-03-26 13:07 ` Julian Phillips
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1269592797-18487-1-git-send-email-icomfort@stanford.edu \
--to=icomfort@stanford.edu \
--cc=bwalton@artsci.utoronto.ca \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).