[Bash-completion-devel] Bits from the Bash-Completion Team

Luk Claes luk at debian.org
Tue May 6 21:22:50 UTC 2008


Steve Kemp wrote:
> On Fri May 02, 2008 at 21:52:41 +0200, David Paleino wrote:
> 
>> A general rule for completion code: bash-completion has always integrated
>> patches in its main code. What we (me and Luk) would like to achieve is to have
>> completion provided by *single* *packages*, not by bash-completion (which would
>> then be just a backend). Example: completion for mount and umount would go into
>> the "mount" package, which would install the respective files
>> into /etc/bash_completion.d/ .
> 
>   I took this to mean that existing completion could be updated for
>  the moment - but that adding completion for whole new commands would
>  be a bad idea; and should happen in the package itself.

Yes.

>   But I guess going forward we need to think about splitting up the
>  main file into a collection of small ones, so for example the ssh/scp
>  code would go into /etc/bash_completion.d/ as a first step, then
>  once we know that doesn't break we submit a bug report against
>  openssh-client to have them include the file.

That's not really a good idea, because that would mean that all these
packages have to Replace bash-completion to be able to have a decent
upgrade path...

>   Does that sound reasonable?  (I guess the downside is timing; if
>  having lots of little files causes things to slow down too much, or
>  perhaps having to coordinate the package release such that we don't
>  have bash-completion + openssh-client both trying to own the same
>  file.)

I would rather ask for the respective packages to ship it in
bash-completion.d and making sure conflicts with the main file don't harm...

If lots of little files causes things to slow down it might be better to
generate one file from all the small ones (regenerating it when some of
these littel files are updated) in /var and use that if available IMHO.

>   I guess 360628 is relevant, as is the contents of the TODO file.

Yes, making it more configurable and more robust would be the goal as I
see it.

What do all of you think?

Cheers

Luk

PS: I see splitting bash-completion as a rather long time goal which
should probably be started in experimental or delayed for the time being.



More information about the Bash-completion-devel mailing list