On 10/16/25 2:15 PM, Iñaki Ucar wrote:
Ok, valuable advice. My current approach is in [1]. I liked the idea of
automating a bunch of things, so I wrote [2]. But feedback is very
welcome, and particularly what would you do instead of this given your
experience.
Sure! You may also be interested in [1] which is a cheatsheet to writing
macros. I'll go through each part of the sample spec you posted:
> %global R_repo cran # repository: cran (default), bioc
I would avoid requiring packagers to set global variables. See in "Avoid
control macros" in the page I linked. Hopefully, you can factor this out
if you remove %R_meta.
> %global R_name example # package name
Same as above.
> %global R_vers 1.2-3 # version in upstream format
Is this necessary? Can't you just set Version to a static value?
> %global R_comp 1 # needs compilation? 0 (default), 1
I would just remove this and require packagers to manually set
BuildArch: noarch if appropriate.
%R_meta # BR R-devel + noarch if needed + compute variables
below
Having a macro add a BuildRequires line to the spec preamble is a bit
magical, and it's only one line that packagers who have to include.
Alternatively, you could create a stub %R_buildrequires that only echoes
R-devel and exits. Then mock will install R-devel which will pull in the
package that includes the fully implemented %R_buildrequires macro and
then mock will re-run %generate_buildrequires, go and install the rest
of the Buildrequires printed by the real %R_buildrequires and then
continue building the package. You can see pyproject-rpm-macros and
pyproject-srpm-macros for an example. Personally, I don't particularly
like this approach. It's a lot of complication and it only saves one
manual BuildRequires line in the specfile.
As for the other macros that it calculates and defines, I would just
define those macros directly in macros.R-srpm instead of using an
intermediate macro to set them with rpm.define within the specfile.
Name: %{R_name_rpm}
The Go macros used to dynamically calculate Name and then the Packaging
Committee asked us to stop. It was a big headache when we needed to make
changes to the name calculation lua code without breaking existing
packages. Also, this can cause various problems when an SRPM is built on
a system that does not have the available macro implementation (or an
old, broken version) that's used to generate Name.
Version: %{R_vers_rpm}
See above.
URL: %{R_url}
Instead of having a macro to define another macro used later in the
specfile (%R_meta defines R_url), you could define a simple parametric
RPM macro named R_url in macros.R-srpm that takes the name of the
project as an argument (or less ideally, reads the variables set earlier
in the spec). See [2] for an example.
Source: %{R_source}
I have the same suggestion as I did for R_url. Statically define a
R_source macro in macros.R-srpm instead of using %R_meta. You can see
%pypi_source in python-srpm-macros as an example.
[1] https://gtmx.me/Wiki/Fedora/developing_rpm_macros/
[2]
https://src.fedoraproject.org/rpms/ansible-packaging/blob/rawhide/f/macros.ansible-srpm
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
