https://bugzilla.redhat.com/show_bug.cgi?id=2142363
Aleksei Bavshin alebastr89@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alebastr89@gmail.com Blocks| |2142334
--- Comment #4 from Aleksei Bavshin alebastr89@gmail.com --- (In reply to Jan Drögehoff from comment #2)
b) Please add a license file
With the answer to a) this would implicitly put all macros under MIT (just like the python macros), but I can add one explicitly if thats desired.
MIT requires that the copyright notice is always distributed along with the sources. This might not be always enforced, but it is the right thing to do. lua-rpm-macros and pyproject-rpm-macros are good recent examples.
d) Maybe the name should just be zig-rpm-macros with the srpm marcos as a subpackage?
That would probably be better, I'll have to work out which macro would be best for each package.
IMO, it would be more convenient to keep the %zig_build family of macros along with the compiler package and lock the versions (e.g. do `Requires: (zig-rpm-macros = %{version} if zig-rpm-macros)` in the main `zig` package). As 0.11.0 has shown, these macros may require backward-incompatible changes. Nonetheless, a standalone zig-rpm-macros package is totally safe with a correct versioning and dependencies. So that's just a matter of your preference.
BTW, %_zig_version is the only macro definition that actually requires data from zig.spec, and I'm not sure if it is even useful.
(In reply to Benson Muite from comment #3)
not sure if a sub package with no main package dependency would work.
Subpackage of `zig` is probably not a good idea for the reasons already explained in bug2142334. Subpackage of a potential `zig-rpm-macros` should be fine.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2142334 [Bug 2142334] `ExclusiveArch: %{zig_arches}` causes build failure in Fedora koji