[Bash-completion-devel] Patch review needed

Ville Skyttä ville.skytta at iki.fi
Mon Sep 21 15:39:26 UTC 2009


On Monday 21 September 2009, Elan Ruusamäe wrote:
> On Monday 21 September 2009 00:35:38 Ville Skyttä wrote:
> > I also have some reservations about 3).  _rpm_installed_packages is used
> > at least by apt in bash-completion, as well as rpmlint and rpmdevtools
> > (both upstream, not in bash-completion) completions, and I'm not at all
> > sure they all handle the name-version-release.arch format.  And I'm not
> > sure if that format buys us much at all - I do see the value in name.arch
> > but the rest seem pretty much just noise to me
> 
> why not check that the other tools can handle complete match?

It's impossible to check everything out there, because we simply can't know 
what exists and relies on the current behavior; I just listed a few I know of.  
Therefore I strongly think that the behavior shouldn't be simply silently 
changed, it either needs to be done by adding a new function that returns 
things with the different format, or adding a parameter that triggers the new 
format, or if everything else fails by prominently documenting the backwards 
incompatible change in release notes.

> i suppose
>  they all eventually route the query to rpm itself, which can handle
>  complete or partial matches...

Some do, some don't.  Some of the ones I mentioned (for example rpmlint) feed 
their arguments to rpm's python bindings which don't work like that; code 
changes are needed.

> as for the nvra matches, if you have several versions of package installed,
> then tab complete should be able to give exact package names which to
> uninstall. adding only .arch would make result still ambigious (in case you
> have two versions of same %{name} installed from same %{arch}).
> 
> having two versions installed is quite common if you run rpm upgrade and
>  old package %postun fails with an error. or if you want to rpm -i/-e some
>  kernel package.

kernel is a good point, that's not at all uncommon.




More information about the Bash-completion-devel mailing list