Bug 1324593
Summary: | Separate bash-completion-devel subpackage | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Yaakov Selkowitz <yselkowi> |
Component: | bash-completion | Assignee: | Ville Skyttä <ville.skytta> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | kdudka, ooprala, sheltren, ville.skytta |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-25 18:00:15 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: | |||
Bug Depends On: | |||
Bug Blocks: | 1323209 |
Description
Yaakov Selkowitz
2016-04-06 17:52:15 UTC
It's not that clear cut, for example the yum-utils completions use pkg-config at "runtime" to pull in the required yum completion functions if they're not available yet. There probably is a prettier way for yum-utils to accomplish the same without needing pkg-config (for example using bash-completion's _xfunc()), and yum and yum-utils are being phased out, but simply going ahead with would cause breakage, so at the moment it's a no go alone. I'm also questioning the necessity to some extent; as far as I can tell, the only dependency in the tree that the *.pc in the main package causes is pkgconfig, and that's roughly a ~120kB package. If the goal is to have a really minimized setup, I wonder why would bash-completion itself be something to include there in such setups (it's ~900kB installed). Leaving open but not sure if anything will happen to this soon. Note that the yum-utils completions are not shipped with bash-completion but with yum-utils itself, nor (as you noted) is yum-utils part of a base install. Sure, that was the thing I was addressing by saying "it's a no go alone" (meaning doing it in bash-completion only without touching other packages that would be affected/broken by the change). What does a "base install" mean, and is bash-completion included in it? It is included in the standard and desktop comps groups. (In reply to Ville Skyttä from comment #1) > I'm also questioning the necessity to some extent; as far as I can tell, the > only dependency in the tree that the *.pc in the main package causes is > pkgconfig, and that's roughly a ~120kB package. If the goal is to have a > really minimized setup, I wonder why would bash-completion itself be > something to include there in such setups (it's ~900kB installed). Fair enough, and I finally managed to track this down; dnf Recommends: bash-completion. Now that we have an option to exclude weak deps in kickstarts (bug 1133110), bash-completion no longer appears in the base image. That being said, bash-completion.pc technically still belongs in a separate -devel package, per the Packaging Guidelines. If a particular third-party completion uses pkg-config (e.g. gstreamer1 or yum-utils), then it should add a weak dep thereon. (In reply to Yaakov Selkowitz from comment #4) > That being said, bash-completion.pc technically still belongs in a separate > -devel package, per the Packaging Guidelines. The packaging guidelines actually acknowledge that it depends on the use case, and in my opinion this is a valid one for having it in the main package. Closing as WONTFIX based on that. https://fedoraproject.org/wiki/Packaging:Guidelines#Pkgconfig_Files_.28foo.pc.29 (In reply to Ville Skyttä from comment #1) > It's not that clear cut, for example the yum-utils completions use > pkg-config at "runtime" to pull in the required yum completion functions if > they're not available yet. That is a reason for yum-utils to depend on pkg-config, not for bash-completion. See the summary of this bug. *.pc files should go to a sub-package that is not installed by default. *** This bug has been marked as a duplicate of bug 1457164 *** |