On 25. 06. 22 19:32, Maxwell G wrote:
Hi Miro,
Thanks for the feedback!
On Saturday, June 25, 2022 5:16:32 AM CDT Miro Hrončok wrote:
> 1) Consider defining the macros in redhat-rpm-config
Yeah, I did think about this, but I figured I'd prefer to have them in a
package that I actually control. This is probably less of a problem for you as
a maintainer of redhat-rpm-config ;-). Also, if I want to backport them to
EPEL, I would have to copy the same thing to epel-rpm-macros and maintain them
in two places.
OK, makes sense. BTW I am not a maintainer of redhat-rpm-config.
> 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.
I'm fine with replacing sh with shell, but what's the point of the `srpm-
macros` part? At least based on what we've discussed so far, there's not
anything in here that's required to build a SRPM.
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. Yes,
technically such macros would not be needed to build a SRPM.
OTOH we *could* make it non-default, but that requires:
BuildRequires: shell-completions-rpm-macros / shell-completions-packaging
...to use them.
> 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/pyt
> hon.attr for a similar example
Thanks for the offer. I did consider writing one, and I do have some
experience with modifying the one that @ignatenkobrain wrote for ansible, but
I thought it might be overcomplicating the problem (which I have a tendency to
do :)). I think your other idea is better, though.
Ack.
I do think I'd like to write an analogue to
`%pyproject_save_files` that would
accept 1 or more completions name globs and find the appropriately named files
in the appropriate directories (name for bash, _name for zsh, name.fish for
fish). %files can accept multiple `-f` arguments (I tested it), so it
shouldn't be a problem for packages to use both.
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 %{bash_completions}
...
> 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.
Yeah, my idea was to create a single component named sh-completions-packaging
(but I can `s/sh/shell/` as you suggested).
> 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.
I agree. The bash completions dir is already owned by filesystem, so we might
as well add the other ones. This is also simpler for me/packagers (I wouldn't
have to write a dependency generator/they wouldn't have to Require the new
package).
+1
The only wrinkle I see is handling this for EPEL. RHEL might take a
PR to own
the zsh completions directory in filesystem, but I doubt they'd own fish
directories as fish is only part of EPEL.
Introduce a filesystem-epel package?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok