Hi,
On 10/17/25 3:38 AM, Iñaki Ucar wrote:
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?
Yes, macros that need to set fields in spec preamble have to be
available at SRPM parse time. If you want to automate these things, then
it's fine to have those macros in the default buildroot. My main concern
is the complicated `%foometa` approach, and I'd also suggest keeping the
Name and Version fields static. Generating URLs and Sources by using
statically defined macros in macros.R-srpm definitely makes sense to me
and does save packager time by avoiding the need to copy complex package
regsitry download URLs.
> %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.
I would caution against dynamically computing the Name: field. Having
Names that can unexpectedly change when the macro code changes seems too
risky for not a lot of benefit.
> %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.
Dynamic Version can cause issues with other tools, especially if it
involves executing lua to determine it. If you really want to automate
Version, would it be possible to do it the other way around: set
Version: statically in the specfile and then define R_vers in
macros.R-srpm (using lua if necessary) based on the standard heuristic
to convert an RPM version to an upstream version? If needed, packagers
could still override R_vers manually in the specfile.
> %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.
What part of the specfile needs to know this? If it's just
`%R_save_files` or the other macros that expand to shell code / calls to
external programs in the RPM %build/%install scripts once the sources
are already unpacked, is there upstream metadata in the sources that the
code could reliably read and then determine which directory to use
instead of requiring packagers to set a macro or trying to read the
value of BuildArch? That would be more robust and prevent packager mistakes.
Best,
Maxwell
--
_______________________________________________
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
