Hi,
On Saturday, June 25, 2022 3:18:55 PM CDT Miro Hrončok wrote:
My understanding was that the new macros would exist in the default
buildroot, hence live in either redhat-rpm-config or in a package required
by
redhat-rpm-config. Such packages should generally be called -srpm-macros.
Yeah, I suppose you're right. All of the macros packages required by redhat-
rpm-config are named X-srpm-macros except rpmautospec-rpm-macros.
OTOH we *could* make it non-default, but that requires:
BuildRequires: shell-completions-rpm-macros / shell-completions-packaging
...to use them.
I'd prefer them to be in the buildroot.
Note that %pyproject_save_files reads upstream metadata, not files on
disk.
Maybe doing this is an overkill?
Consider this:
%files
...
%{bash_completions}/foo
Vs:
%install
...
%save_bash_completions foo
%files -f %
Well,
```
%install
[...]
%sh_completions_save_files X
%files -f %{sh_completions_files}
```
is shorter than
```
%files
%{bash_completions_dir}/X
%{zsh_completions_dir}/_X
%{fish_completions_dir}/X.fish
```
but even with that slightly larger difference, it still probably isn't worth
the trouble. It would be more useful if we could automate installing them
also, but that wouldn't work well due to the varying ways these files are
generated and organized in upstream repos.
Introduce a filesystem-epel package?
+1. I guess we could add that as a subpackage to epel-release.
Thanks again for the advice. If it's really only three static macros that I'm
adding, I'm thinking it probably isn't worth creating a separate component,
which is what you said in the first place :). redhat-rpm-config's repo
structure and the divergent git branches and changelogs are just really
annoying to work with :(.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His