Thanks for all the feedback! Comments inline:
On Thu, 16 Oct 2025 at 22:12, Maxwell G <[email protected]> wrote:
> 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.
This is very useful, thank you.
> 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.
>
The thing is that we already have to set several global variables. I'm
trying here at least to have some benefit out of it via automation.
About this in particular, there are two standard repositories, and the goal
would be to automate the URL and Source fields. Of course, I could also
generate a %cran_url, %cran_source, %bioc_url, and %bioc_source macros
instead. But then again, I would still need to put them in the default
buildroot, right? You said "I would suggest you consider refactoring your
macros so they don't need to be installed at SRPM parse time", and I agree
this would be perfect, but then, many cumbersome things happens with the
URL's, name, version and library placement (more of this below), so,
correct me if I'm wrong, but any kind of automation here needs to be
installed at SRPM parse time, right?
> %global R_name example # package name
>
> Same as above.
>
The upstream package name is used in many places, and it's different from
the rpm name, so basically all specs are currently setting a global
variable for this.
> > %global R_vers 1.2-3 # version in upstream format
>
> Is this necessary? Can't you just set Version to a static value?
>
Sometimes, when the upstream version is compatible with our versioning
system. But many times it's not, like the one in the example, that has a
"-". In those cases, the upstream version is used in several places, and
the rpm version in some others. So packages are already defining one
(sometimes several) global variables for this. Or they have to update the
version in several places, which is prone to errors.
> > %global R_comp 1 # needs compilation? 0 (default), 1
>
> I would just remove this and require packagers to manually set
> BuildArch: noarch if appropriate.
>
The thing is that it's not only the BuildArch. Packages go into different
directories depending on this. Currently, packages have to set
%global rlibdir %{_libdir}/R/library
for packages that require compilation, and
%global rlibdir %{_datadir}/R/library
+ BuildArch: noarch for packages that don't. This global is more obscure in
my opinion. So I'd like to automate it. Can I check with a macro if
BuildArch: noarch was set?
> > %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.
>
So basically you don't recommend the automagic of such a macro, right? But
as discussed above, the main problem still persists: SRPM macros need to be
required in the default buildroot. So my line of thought was: given that I
have to do this anyway, why not improve everyone else's life? :)
> > 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.
>
I'd really really really like to automate 3 things:
- Version normalization, so that the packager defines just the upstream
version in the header, as a global variable, and then some macro takes care
of setting the proper rpm version, etc.
- Setting the rlibdir appropriately (see above two comments ago).
- Setting URLs and Sources automatically.
I agree that setting this automagic name vs manually setting R-%{R_name} is
not much of a difference. But I thought that, given the automations above,
it would be better to set this one too for consistency. Here the name
calculation is pretty straightforward and it's not expected to change.
> > 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
>
I'll take a look, thanks.
Best,
--
Iñaki Úcar
--
_______________________________________________
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
