On 24. 06. 22 21:26, Maxwell G wrote:
Hi everyone,
Currently, packaging shell completions is a bit of a hassle. You have to
memorize a bunch of long directory names (`%{_datadir}/bash-completion/
completions`, `%{_datadir}/fish/vendor_completions.d`, and `%{_datadir}/zsh/
site-functions`), and repeat them multiple times in the specfile. For some
reason, the bash completion directories are owned by filesystem, but zsh and
fish's shell completions directories are not. Therefore, every package needs
to copy
```
%files
[...]
%{_datadir}/bash-completion/completions/%{name}
%dir %{_datadir}/fish
%dir %{_datadir}/fish/vendor_completions.d
%{_datadir}/fish/vendor_completions.d/%{name}.fish
%dir %{_datadir}/zsh
%dir %{_datadir}/zsh/site-functions
%{_datadir}/zsh/site-functions/_%{name}
```
or own each shell's respective root directory and not bother with `%dir`
and explicit paths. I don't like doing the latter, as I prefer to be explicit
and follow the spirit of https://docs.fedoraproject.org/en-US/packaging-guidelines/#_explicit_lists.
I was thinking of creating an sh-completions-packaging package (name
suggestions welcome) that provides a subpackage containing macros for each of
those directories that would be part of the default buildroot and a filesystem
subpackage that owns these directories so packages can Require it and not have
to copy this long boiler plate.
I would appreciate any feedback you have, particularly regarding naming of the
packages and macros. For the macros, would `%{_bashcompdir}`,
`%{_zshcompdir}`, and `%{_fishcompdir}` be appropriate macro names? I'm a bit
unclear about macro namespacing conventions.
Even if you don't like this idea, I think the guidelines could at least use
some clarification in this area. I have seen or dealt with multiple packages
that install shell completions to the wrong directories, don't properly own the
directories, or have other problems.
I welcome the idea. Some suggestions:
1) Consider defining the macros in redhat-rpm-config -- I do not except they
would change often and would need a separate component -- new component might
get dropped from RHEL 10 because RHEL maintainers want to get rid of
components, it also means more metadata and generally is a waste of resources.
2) If you insist on new component, I'd name it shell-completions-rpm-macros
and the built package shell-completions-srpm-macros if it is required by
redhat-rpm-config.
3) If you want the filesystem stuff to be subpackages, consider adding a
dependency generator (package installs files to Bash completion dir -> depends
on shell-completions-filesystem-bash) -- I can help write it, but see e.g.
https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/python.attr
for a similar example
4) If you go with your own component and subpackages, consider making the
filesystem subpackages part of this component, so it's easier to do changes
atomicaly at one place.
4) However, I'd consider adding the directories to filesystem directly to
make it simpler and avoid any new dependencies. It's less cool, but also less code.
5) %{bash_completions_dir}, %{fih_completions_dir}, %{zsh_completions_dir}
or %{bash_completions}, %{fih_completions}, %{zsh_completions}
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
