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
>packages.
>
>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.
OK.
>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
package.
Reply to: