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
_______________________________________________
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
