| Summary: | bash/fish completion file should be moved to docker-common | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Carl George <carl> |
| Component: | docker | Assignee: | Jindrich Novy <jnovy> |
| Status: | CLOSED WONTFIX | QA Contact: | atomic-bugs <atomic-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | amurdaca, dwalsh, lsm5, tn, tsweeney |
| Target Milestone: | rc | Keywords: | Extras |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-06-09 21:13:12 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Carl George
2016-11-07 15:40:06 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) 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. Not certain, but I guess we could account for different completion paths in the wrapper script itself, couldn't we? 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
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. lokesh any update on this? 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. |