This way tools that want to ship fish configuration don't need to depend on fish. Fish has never owned %{_datadir}/fish/vendor_conf.d, so there won't be any coordination needed there. If you want to coordinate on handing off %{_datadir}/fish/vendor_completions.d, let me know -- I'd be glad to do a new set of fish builds and let you package them into the same update as filesystem. Ideally we'd do this all the way back to f22 so that dependent packages don't need to worry about differences between releases. The fish update that consumes vendor_conf.d is building now.
FWIW, if you feel that this doesn't belong in filesystem, I could easily add a tiny fish-filesystem package for these directories.
Thanks for the report... I'm 50:50 here... On the one hand, filesystem already owns completion directories for other shells. On the other hand, fish shell is not yet widely adopted - in contrary to other shells where filesystem owns the directories. I like fish shell, but I want to prevent bloat. Therefore fish-filesystem subpackage is my preference for now, once/if the usage of fish generally increases, we can easily move it to generic filesystem package. Does that work for you? Or do you have some argument for having this in the primary filesystem package?
I would say the common practice is to own the directory by each package that installs a shell-specific file in there. You can have a look which packages own similar directories used by bash or zsh (none of them is owned by setup): $ rpm -qf /usr/share/bash-completion | sort bash-completion-2.1-8.20150513git1950590.fc23.noarch beaker-client-19.1-1.fc19.noarch bzr-2.6.0-12.fc23.x86_64 cmake-3.4.1-4.fc23.x86_64 createrepo-0.10.3-3.fc21.noarch devscripts-2.15.10-2.fc23.x86_64 dnf-1.1.6-2.fc23.noarch git-core-2.5.0-4.fc23.x86_64 glib2-2.46.2-1.fc23.i686 glib2-2.46.2-1.fc23.x86_64 gvfs-client-1.26.2-1.fc23.x86_64 kmod-22-2.fc23.x86_64 mercurial-3.5.1-1.fc23.x86_64 npm-1.3.6-8.fc23.noarch python3-pip-7.1.0-1.fc23.noarch python-django-bash-completion-1.8.8-1.fc23.noarch python-pip-7.1.0-1.fc23.noarch rpmdevtools-8.6-2.fc23.noarch rpmlint-1.8-4.fc23.noarch source-highlight-3.1.8-4.fc23.x86_64 subversion-1.9.3-1.fc23.x86_64 tig-2.1.1-2.fc23.x86_64 vagrant-1.8.1-1.fc23.noarch yum-3.4.3-507.fc23.noarch $ rpm -qf /usr/share/zsh | sort mercurial-3.5.1-1.fc23.x86_64 pulseaudio-7.1-1.fc23.x86_64 systemd-222-14.fc23.x86_64 zsh-5.2-4.fc23.x86_64
At least for bash-completion there is a request to move the ownership to filesystem package.
The packaging guidelines explicitly give bash-completion as an example for which having multiple packages co-own the directory makes sense. Is there something wrong with doing this? I have no real problem with having both fish and e.g. ccache co-own the relevant directory.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
(In reply to Andy Lutomirski from comment #0) > Fish has never owned %{_datadir}/fish/vendor_conf.d, so there won't be any > coordination needed there. If you want to coordinate on handing off > %{_datadir}/fish/vendor_completions.d, let me know -- I'd be glad to do a > new set of fish builds and let you package them into the same update as > filesystem. Hello Andy, While going through the backlog BZs for filesystem I got to your BZ. Maybe, I am overlooking something but it looks like the fish owned those directories since the beginning...: https://src.fedoraproject.org/rpms/fish/blob/b1dfe6a45462ff95d71ca19ec52fe075636366dc/f/fish.spec#_97 ~~~ %{_datadir}/fish/ ~~~ ...8 years ago - missing `%dir` before the above path, so all the dirs below got owned when vendor_conf.d & vendor_completions.d got added: https://src.fedoraproject.org/rpms/fish/c/02934d01cac6268694bad707db2faccf3c9dbe14 https://src.fedoraproject.org/rpms/fish/blame/fish.spec?identifier=02934d01cac6268694bad707db2faccf3c9dbe14#_118 Anyway, this has been opened for such a long time and fish still owns these directories: https://src.fedoraproject.org/rpms/fish/blob/9c1c77356bda0f0412388733f442c34dcd5940c7/f/fish.spec#_138 besides alacritty: ~~~ $ mock -r fedora-rawhide-x86_64 -i fish $ mock -r fedora-rawhide-x86_64 -i /usr/share/fish/{vendor_conf.d,vendor_completions.d}/\* $ mock -r fedora-rawhide-x86_64 shell ... <mock-chroot> sh-5.1# rpm -qf /usr/share/fish/{vendor_conf.d,vendor_completions.d} fish-3.5.0-2.fc37.x86_64 fish-3.5.0-2.fc37.x86_64 alacritty-0.10.1-3.fc37.x86_64 <mock-chroot> sh-5.1# ~~~ With that said in connection to what is mentioned in comment 2 and comment 3 I decided to close this as WONTFIX because owning these directories by filesystem is not needed - there are no unowned directories. Please, feel free to reopen if you *strongly* disagree.
I think what you may be overlooking is that packages should be able to ship a completion file without having to own the completions directory, or require the shell that owns that completion directory. Take for example the completion files shipped in the bat package. [root@f37-container:~]# repoquery --quiet --list bat | grep -e bash -e zsh -e fish /usr/share/bash-completion/completions/bat /usr/share/fish /usr/share/fish/vendor_completions.d /usr/share/fish/vendor_completions.d/bat.fish /usr/share/zsh /usr/share/zsh/site-functions /usr/share/zsh/site-functions/_bat Bash is easy because /usr/share/bash-completion/completions/ and /usr/share/bash-completion/ are owned by the filesystem package. But for fish and zsh, the parent directories must be owned by bat in order to comply with the packaging guidelines [0]. The only alternative would be for bat to require fish and zsh, which is not desirable because a bash user who wants to install bat should not also have to install two unrelated shells. Many packagers just mess this up and don't do either, resulting in unowned directories. Here is a reproducer. [carl@teal:~]$ podman run -it --rm fedora:36 [root@fde92b84a15f /]# dnf -y install bspwm ---snip--- [root@fde92b84a15f /]# rpm -qf /usr/share/fish/ /usr/share/fish/vendor_completions.d/ file /usr/share/fish is not owned by any package file /usr/share/fish/vendor_completions.d is not owned by any package The correct answer is for the filesystem package to own the completion directories for fish and zsh just like it does for bash to make it easier for packagers to ship completion files. I do not think it's necessary to have filesystem own /usr/share/fish/vendor_conf.d/ as that is not a completion directory. Please add the following directories to the filesystem package. /usr/share/fish /usr/share/fish/vendor_completions.d /usr/share/zsh /usr/share/zsh/site-functions [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/
It looks like https://src.fedoraproject.org/rpms/filesystem/pull-request/7 will solve this (it just needs to be rebased).
https://pagure.io/filesystem/pull-request/7
FEDORA-2022-5fd3ebac2e has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-5fd3ebac2e
FEDORA-2022-5fd3ebac2e has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-7ea518a8c7 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7ea518a8c7
FEDORA-2022-7ea518a8c7 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-7ea518a8c7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7ea518a8c7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-7ea518a8c7 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.