Bug 1190671
| Summary: | DNF ships bash completition file but lacks requirement on bash completion | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jóhann B. Guðmundsson <johannbg> |
| Component: | dnf | Assignee: | Honza Silhan <jsilhan> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | akozumpl, fedora, jsilhan, mluscon, pnemade, rholy, tim.lauridsen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | dnf-plugins-extras-0.0.6-2.fc22 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-04-06 18:49:10 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: | |
| Embargoed: | |||
Installing completion without the bash-completion package is fine (just missing the directory ownership then). It should be put into /usr/share though. Plenty of packages ship zsh completion without a requirement on zsh itself. (In reply to Ben Boeckel from comment #1) > Installing completion without the bash-completion package is fine (just > missing the directory ownership then). It should be put into /usr/share > though. Plenty of packages ship zsh completion without a requirement on zsh > itself. Spoken as an individual that has never had to deal with brokenness or features in the distribution. This is outright wrong you should *always* depend on the relevant component for the files you ship but are depended on the presence of another component being installed on the system to function correctly or function et all. We have been bitten pretty badly on this broken workflow of maintainers ( which is arguably due to FESCo/FPC incompetence atleast for those maintainers that actually try to follow the FPG to the best of their ability ) when trying to get accurate scope on how upstream changes affect the distribution in whole and in turn be able to deal with it properly ( and fix any fallout ) during the distributions development cycle ( as opposed to have to deal with the fallout afterward the distribution has been released ). Now I would say the correct thing to do for shell completions in general is to have them shipped in the relevant completion package for a given shell for all the components that provide that since the *correct* alternative is to have them shipped in a sub-component and have that component depend on the relevant shell completion package. But given I know how utterly and completely incompetent and useless FPC is, I have absolutely no intention to deal with them since it's a waste of mine and others time ( and is the reason why maintainers are bypassing that distribution process in the masses ). The problem is that if I want completion for a command, if it is shipped in a subpackage, I have to manually hunt it down (and if I switch shells, do it again), so, IMO, that makes subpackages for shell completion largely useless. So from there, we're shipping it in the main package. Now the main package can plausibly depend on zsh, fish, bash-completion, and csh if it contains completions for all of those. Those are, to me, completely superfluous dependencies. I don't see this as any different than packages which ship PDF or HTML docs not putting a Requires a PDF viewer or a web browser (do we even have virtual Provides for either of those things?). The dependency is unnecessary and the subpackage is fiddly. AFAIK, manpages and info docs also don't require a viewer to be present. However, with weak dependencies, subpackages can become viable again: a shell Suggests all known completions around or the subpackage Enhances the shell it is for (probably the better of the two). The former is a maintenance nightmare and the latter means *lots* more packages where the RPM metadata is likely larger than the content. (In reply to Ben Boeckel from comment #3) > The problem is that if I want completion for a command, if it is shipped in > a subpackage, I have to manually hunt it down (and if I switch shells, do it > again), so, IMO, that makes subpackages for shell completion largely > useless. So from there, we're shipping it in the main package. Now the main > package can plausibly depend on zsh, fish, bash-completion, and csh if it > contains completions for all of those. Those are, to me, completely > superfluous dependencies. I don't see this as any different than packages > which ship PDF or HTML docs not putting a Requires a PDF viewer or a web > browser (do we even have virtual Provides for either of those things?). The > dependency is unnecessary and the subpackage is fiddly. AFAIK, manpages and > info docs also don't require a viewer to be present. > > However, with weak dependencies, subpackages can become viable again: a > shell Suggests all known completions around or the subpackage Enhances the > shell it is for (probably the better of the two). The former is a > maintenance nightmare and the latter means *lots* more packages where the > RPM metadata is likely larger than the content. As I mentioned earlier the best solution is to ship ( in this case dnf-completion.bash ) file in the bash-completition package itself as is being done for quite alot of components already. ( ls -alh /usr/share/bash-completion/completions/ | wc -l 772 ) So everyone has to wait for a bash-completion release then distro update with the proper updates once a program is updated? I prefer upstream to have the completion so it is always in sync with the program itself, so maybe that's the root of the difference of opinion here. (In reply to Ben Boeckel from comment #5) > So everyone has to wait for a bash-completion release then distro update > with the proper updates once a program is updated? I prefer upstream to have > the completion so it is always in sync with the program itself, so maybe > that's the root of the difference of opinion here. That argument is moot since such ( invasive ) changes would never be made in Fedora and would be released in sync with rolling release distribution. I guess the difference of opinion here is that upstream should not get involved with shipping bash competition scripts et all and if they choose to do so the downstream maintainers just have to suck it up and properly package it into sub-components per shell. (In reply to Jóhann B. Guðmundsson from comment #6) > That argument is moot since such ( invasive ) changes would never be made in > Fedora Uh huh... I'm going to assume you mean "should" rather than "would" here. Git has been uplifted within a release (I see 1.8.4 and 2.1.0 builds for F21 in Koji though 2.0.x was likely in F21-Alpha by the dates). > and would be released in sync with rolling release distribution. Heh. I'm going to go ahead and assume you don't use Rawhide? Getting even builds synced up would be wonderful (just look at the size of the broken dependency report in Rawhide on devel@). Getting backports/release bumps for shell completion synchronized is a pipe dream for now. I also don't think such things cross the minds of Arch or Gentoo maintainers; there are bigger fish to fry. > I guess the difference of opinion here is that upstream should not get > involved with shipping bash competition scripts et all and if they choose to > do so the downstream maintainers just have to suck it up and properly > package it into sub-components per shell. *shrug* IME, that has rarely turned out well in the long run. For example, it took somewhere around a year before zsh's git completion (as shipped by Fedora) understood --set-upstream-to= properly. There have been other times when shell-shipped completions have been poor because they try to support a menagerie of versions/implementations at the same time (e.g., BSD utils vs. coreutils, zsh's _tmux is almost never valid for me since I tend to run master, etc.). This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 Thanks for the report. PR: https://github.com/rpm-software-management/dnf/pull/239 hawkey-0.5.4-1.fc22,dnf-0.6.5-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/hawkey-0.5.4-1.fc22,dnf-0.6.5-1.fc22 Package hawkey-0.5.4-1.fc22, dnf-0.6.5-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hawkey-0.5.4-1.fc22 dnf-0.6.5-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-5337/hawkey-0.5.4-1.fc22,dnf-0.6.5-1.fc22 then log in and leave karma (feedback). dnf-plugins-extras-0.0.6-2.fc22,yum-utils-1.1.31-505.fc22,yum-3.4.3-505.fc22,hawkey-0.5.4-1.fc22,dnf-0.6.5-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/dnf-plugins-extras-0.0.6-2.fc22,yum-utils-1.1.31-505.fc22,yum-3.4.3-505.fc22,hawkey-0.5.4-1.fc22,dnf-0.6.5-1.fc22 dnf-plugins-extras-0.0.6-2.fc22, yum-3.4.3-505.fc22, dnf-0.6.5-1.fc22, yum-utils-1.1.31-505.fc22, hawkey-0.5.4-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: dnf ships bash completion file ( /etc/bash_completion.d/dnf-completion.bash ) but lack requirement on bash-completion and installs it incorrectly under /etc as well as marks it as a config file which it is not Requires: deltarpm Requires: libreport-filesystem Requires: pygpgme Requires: pyliblzma Requires: python-hawkey >= %{hawkey_version} Requires: python-iniparse Requires: python-libcomps >= %{libcomps_version} Requires: python-librepo >= %{librepo_version} Requires: rpm-plugin-systemd-inhibit Requires: rpm-python >= %{rpm_version} Requires(post): systemd Requires(preun): systemd Requires(postun): systemd ... %config %{_sysconfdir}/bash_completion.d/dnf-completion.bash Should look more like this BuildRequires: bash-completion Requires: bash-completion %{_datadir}/bash-completion/completions/dnf Note this will in turn indirectly add dependency on bash so arguably this should also be split in it's own sub package Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: