Bug 1392503 - bash/fish completion file should be moved to docker-common
Summary: bash/fish completion file should be moved to docker-common
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jindrich Novy
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-07 15:40 UTC by Carl George
Modified: 2020-06-09 21:13 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-09 21:13:12 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Carl George 2016-11-07 15:40:06 UTC
Description of problem:
The bash and fish completion files are owned by the docker package.  They should move to the docker-common subpackage so that docker-latest can use them as well.

Version-Release number of selected component (if applicable):
docker-1.10.3-57.el7.x86_64

Steps to Reproduce:
1. yum install docker-latest
2. completion files are not installed and completion doesn't work

Comment 1 Antonio Murdaca 2016-11-07 16:04:16 UTC
No, docker-latest should ship its own completion files since completions cannot be shared between docker versions (1.12.3 has more autocomplete flags than 1.10.3 for instance)

Comment 2 Carl George 2016-11-07 20:21:31 UTC
A separate completion file for docker-latest would have to be use a different path than the one for docker (/usr/share/bash-completion/completions/docker), which would prevent it from working correctly with the /usr/bin/docker wrapper script.

The only way I see this working is making the completion files compatible with both docker (1.10) and docker-latest (1.12) and being part of docker-common (shipped with the /usr/bin/docker wrapper script), even if that means some options are missing for docker-latest.

Comment 4 Lokesh Mandvekar 2017-01-18 19:07:12 UTC
Not certain, but I guess we could account for different completion paths in the wrapper script itself, couldn't we?

Comment 5 Carl George 2017-01-18 19:35:44 UTC
Looks like docker and docker-latest are now the same version, and both ship their own completion files.

# rpm -qf /usr/share/bash-completion/completions/docker{,-latest}
docker-1.12.5-14.el7.x86_64
docker-latest-1.12.5-14.el7.x86_64
# rpm -qf /usr/share/fish/vendor_completions.d/docker{,-latest}.fish
docker-1.12.5-14.el7.x86_64
docker-latest-1.12.5-14.el7.x86_64

Comment 6 tn 2017-01-24 14:43:03 UTC
I think the most appropriate solution is to have one completion file in -common that sources /etc/sysconfig/docker and checks DOCKERBINARY just like the /usr/bin/docker wrapper does (maybe that logic can be extracted and reused, but it's quite trivial). Based on that it, in turn, sources the appropriate completion file.


Anyway, in the meantime, here's a per-user workaround when only docker-latest is installed for example:

$ ln --symbolic /usr/share/bash-completion/completions/docker-latest $HOME/.local/share/bash-completion/completions/docker

In theory not a good idea if you expect the system to switch its DOCKERBINARY setting often, especially if/when -current is pre 1.13 and -latest is post 1.13 as there were quite a few CLI updates. In practice it'll be rare, harmless, you'll see this immediately (in fact you'll probably be the one doing the upgrade) and you can just update the link.

Comment 7 Daniel Walsh 2017-06-30 14:56:02 UTC
lokesh any update on this?

Comment 8 Tom Sweeney 2020-06-09 21:13:12 UTC
We have no plans to ship another version of Docker at this time. RHEL7 is in final support stages where only security fixes will get released.  Customers should move to use Podman which is available starting in RHEL 7.6.


Note You need to log in before you can comment on or make changes to this bug.