[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#876095: O: bash-completion -- programmable completion for the bash shell

Hi, Axel.

Thanks for the review and explanations. :)

On 02 Oct 2017, Axel Beckert wrote:
>sorry for the late reply. Replying to your original mail as I already
>had written half the mail a few days ago.

Thank you!
I only sent a new email because I have found some answers and because I
have progressed with the packaging to a point where it might make sense
to share it (through mentors).

>This is a very common issue with bash-completion and zsh-common (where
>zsh's default completions live), but it's also unique to those two
>Background: Some projects maintain shell completions rather well,
>others don't, but the team maintaining the completions does maintain
>them. If new completions are added to bash-completions, it's often a
>sign that the project they're for, doesn't really maintain them.


>So you should compare the conflicting files: Which are more uptodate,
>which have more precise completion.
>If it's the one in the project's package, just don't ship the one in
>bash-completion and it's good.

Makes sense.

>If the newly appeared file in bash-completion is clearly the better,
>you should maybe not ship it now, but file a bug report against the
>other package to exclude it, and if that's done, add in your next
>upload Breaks + Replaces headers against the last version of the
>package which still contained the conflicting file.

Makes sense.  In the packaging I already did, I removed the conflicting
files.  Based on your comment, I'll analyze which of them is better,
than if it's bash-completion's, I'll file a bug report agains the other

Reply to: