[Bash-completion-devel] [patch review] Add --rsyncable to gzip completion

[Ville Skyttä]

On Saturday 17 January 2009, you wrote:
> El sáb, 17-01-2009 a las 02:47 +0200, Ville Skyttä escribió:
> > On Saturday 17 January 2009, Santiago M. Mola wrote:

> David changed gzip completion to parse gzip --help, so it's fixed now.

Good stuff.  The implementation does seem to overlap the functionality of 
_longopt a bit though (or the other way around), but that's more or less 
cosmetic.

Note about what follows: I'm not trying to be an ass or to force feed my 
opinions, but new here (but not new to bash-completion), rather trying to 
develop a gut feeling what people think bash-completion should or should not 
do.

> > distros I have access to or otherwise looked at their sources (Fedora,
> > CentOS, openSUSE, Mandriva, Debian; all of these had --rsyncable).
>
> That's still a tiny subset of available distros,

Not really if you take into account the derivatives of those (which I assume 
do also carry that patch).  But yep, then there's all the non-Linux 
environments where bash-completion is supposed to work as well.

> which is quite opposite to "practical portability".

I disagree.

> Gentoo, for example, hasn't --rsyncable option.

We'll always find some setups that do not have everything we expect, and we 
have to make assumptions.  Nobody can test every setup available out there, 
and judgement calls have to be made.  And we're all more or less biased - if 
Gentoo had --rsyncable, would you have objected to this addition?

> I hope in the future we take the most generic approach (when possible),
> specially when talking about distro-specific options.

If the vast majority of target environments has something and a handful does 
not (patched in or not, and not specifically referring to gzip --rsyncable 
here), which one of these is the exception that we should leave to users or 
package maintainers of those environments?

> That is, the lowest common denominator policy

Personally, I certainly hope this is not going to happen.

> or automatic guessing. 

If by this you mean things like parsing the available options dynamically from 
somewhere, it is clearly a winner when it can be done robustly.

> On some projects, bash-completion modules are shipped with upstream
> tarballs and maintained there,

This is good (as long as they're really maintained in addition to being 
included)...

> so people always have the correct version installed.

...but one problem is that a lot of upstream projects that ship completions do 
not actually install them, users or package maintainers need to take care of 
that.  I suppose better filesystem layout for bash-completion and 
documentation about it could change this.  Ditto mentioning what is the 
stable API (various helper functions etc) of bash-completion that external 
module writers can rely on being available.  These would probably have a 
positive effect on more upstreams' willingness to include completion modules 
in their source trees and deliverables in the first place, not only 
the "include but do not install" part.