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. > 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. > 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. 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. > 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). 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. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ 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
