On Sunday 20 September 2009, Guillaume Rousse wrote: > 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;
I don't think syntactic or stylistic issues are anything to be concerned about. Regarding functionality, I don't think it would be impossible for upstreams to do practically as good job as we (or even better), but we should make it easier for them: define a stable well documented API they can count on being available and not change. This would consist of both functions and completion snippet dir location stability (perhaps a pkg-config file or something for the latter would be a good idea). When completions are included/installed from upstream packages, there is room for improvements that we can't as easily do, which I believe in the long run can result in _better_ functionality/performance/end user experience than we can provide: - No need to do any have() or trigger games, when installed with rest of the upstream software, it is known that the completed commands are there. - No need to keep completion stuff for old versions of the software around nor try to be careful or do guesses what the commands might look in the future: just keep it up to date with the released version - it doesn't have to work with anything else except that. We on the other hand should provide documented and stable helpers that work regardless of (supported) bash version and to the extent possible, across operating systems. > > 2) we would lose maintainance of the completions. Frankly, I think this would be a good trend ;) > > 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. Nah, these should be exceptional cases. If someone wants to maintain something upstream, by all means do it, but there should be no actual requirement for this. > > 3) bash-completion will rapidly decrease in performance, because of > > probably poorly written code. I don't buy this. > 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. This is surely a bit (yep, a bit, not a lot) of work, but why would it be impossible? I haven't packaged post 1.0 bash-completion for Fedora but I do for now intend to continue with the trigger approach. With a few helper macros I think it's quite manageable, see http://cvs.fedoraproject.org/viewvc/rpms/bash-completion/devel/bash- completion.spec?revision=1.42&view=markup > The intent of the script I recently commited in the project > (install-completions), is to leverage this problem, I'll however intend to look into this script as well. _______________________________________________ Bash-completion-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
