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

Guillaume Rousse Guillaume.Rousse at inria.fr
Sun Sep 20 20:06:16 UTC 2009


David Paleino a écrit :
> Hello,
> I remember we decided to push all completions to respective upstreams, but
> didn't decide anything more than that, at the time. -- or it could've been a
> joke of my mind :)
> 
> On IRC the discussion was raised by the maintainer of the PLD package. He has a
> few points, which I believe we already discussed about, with some new features:
> 
> 1) upstreams won't possibly handle completions like we can -- be it
>    syntactically, stylistically, functionally;
> 2) we would lose maintainance of the completions. Or, if we want to keep it, it
>    would be a nightmare: we would need a $vcs write access for the completion
>    for each software package. A mess.
> 3) bash-completion will rapidly decrease in performance, because of probably
>    poorly written code.
> 
> The proposal made by Elan is: let's keep all completions in our repository
> (and released package), and use package managers "triggers" to install them. I
> know .deb has it (but never done that, should do a bit of research), and Elan
> said .rpm has that too. What about emerge? Other distros?
> 
> Obviously, before using these "triggers", we should change directory layout.
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. 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.

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.

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.
-- 
BOFH excuse #304:

routing problems on the neural net



More information about the Bash-completion-devel mailing list