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

[David Paleino]

On Tue, 06 May 2008 23:22:50 +0200, Luk Claes wrote:

> 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.

Agreed.
Currently, in my local bzr checkout, I've added completion for rrdtool, and
applied patches from the BTS. I'm going to commit that soon, please review for
any problem you might spot.

> >   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...

Or, we could create a virtual package "bash-completion-rule", which would be
a Provides: in those packages. But that's a "major architectural change" IMHO,
and should be done slowly :)

> >   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...

Agreed on this.

> 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.

We should make some timing tests for this.

> >   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.

Yes.
But we should also think of writing everything from zero, i.e. removing all the
bash2.* things. IMHO that would make things faster (i.e. less tests to do since
we know we are on bash3.*, ...)

Just my 2cents,
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: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20080510/39c730d4/attachment.pgp