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
_______________________________________________
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
