[Bash-completion-devel] [RFC] Completions location

[David Paleino]

On Sun, 20 Sep 2009 22:06:16 +0200, Guillaume Rousse wrote:

> You're mixing two issues here.
> 
> The first one is where is the code to be developped and maintained: 
> either splitted in various upstream projects, or centralized in 
> bash-completion project.
> 
> The second one is where the the code is to be packaged in various linux 
> distributions, either splitted in various packages, or centralized in 
> bash-completion package.
> 
> The two issues are only loosely related.

Not really, IMHO :) (see next paragraph)

> For instance, in Mandriva, various completions were shipped in the package
> they were related to, even if developped elsewhere. Of course, mapping
> packages to software projects is usually easier on the long term, that's why
> I reverted to the centralised distribution in bash-completion package.

Exactly: there's a *big* maintainance overhead for distributions, if
we keep completions in our project and have to ship them on a per-package
basis downstream.

> For the last issue, which is to distribute in a single package, and 
> activate only when needed, I initially attempted to use triggers too. 
> However, we now have 175 various completions in contrib directories, 
> meaning 175 * 2 triggers (installation/uninstallation) to maintain, 
> keeping track of the various mismatch between package names and 
> completion file name. All in all, that's just impossible.

Is it necessary to do that manually?
I mean, when I thought at completions "using triggers", I was imagening the
following scenario:

  a) we have a package "foo" downstream, for which we created a completion
     "foo" in our project;
  b) the package maintainer of "foo" does "something" to activate "foo"
     completion. In the simplest case, symlinks the completion
     from /usr/share/bash-completion/contrib/foo to /etc/bash_completion.d/foo;
  c) this would've been done automatically, i.e. by *default* if there's a
     matching completion in /usr/share/bash-completion/contrib/, symlink it to
     the proper location.

Regarding point c), I was thinking at packages matching the completion name.
But there could also be completions whose name doesn't match with the
downstream package name. In this case, I was thinking that's maintainer's duty
(if the names don't match, otherwise it's automatically done) to specify in
some "field" (in debian/control, or in RPM's .spec) the completions to
activate if available.

This way, each time we create a new completion, we just need to file a bug to
the respective downstream packages, something like "hey, beware that in next
bash-completion release, you will have this additional completion. Please
handle it appropriately".

> The intent of the script I recently commited in the project 
> (install-completions), is to leverage this problem, by automatically 
> selecting which completions from installation directory (for instance, 
> /usr/share/bash-completion) are relevant, and symlinking them to the 
> place where they are actually sourced (/etc/bash-completion.d). This 
> way, I just have to call 'install-completions /usr/share/bash-completion 
> /etc/bash-completion.d' during package post-installation procedure, and 
> 'symlinks -d /etc/bash-completion.d' during post-uninstallation 
> procedure. Of course, this does not automatically add new completions 
> for packages installed later, but users are also able to rerun the 
> script themselves.

That's fine when the user installs bash-completion -- and when upgrades it, but
we'd totally lose completions for installed programs during the two releases
(be them up- or downstream).

And, in my opinion, giving the user a cli command to activate them, shouldn't
be the only way to go -- at most that can be an helper script, when "triggers"
aren't supported in the distribution. IMHO this should be transparent to the
user:

  1) user installs bash-completion, and it makes symlinks for installed packages
  2) each package installation "triggers" the completion activation (with the
     mechanisms I explained above)

If any of my points is not clear, I'm all open to discussion :)

Thanks for your contribution,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20090920/44d2a604/attachment.pgp>