RPMException: parse error in expression: %{fedora} >= 39

[sentry-io[bot]]

Sentry Issue: PCKT-002-PACKIT-SERVICE-8DP

ValueError: can't parse specfile

  File "specfile/spec_parser.py", line 226, in get_rpm_spec
    return rpm.spec(tmp.name, flags)

RPMException: parse error in expression:  %{fedora} >= 39
(4 additional frame(s) were not displayed)
...
  File "packit/base_git.py", line 132, in specfile
    self._specfile = Specfile(
  File "specfile/specfile.py", line 80, in __init__
    self._parser.parse(str(self))
  File "specfile/spec_parser.py", line 380, in parse
    self.spec, self.tainted = self._do_parse(content, extra_macros)
  File "specfile/spec_parser.py", line 294, in _do_parse
    spec = get_rpm_spec(content, rpm.RPMSPEC_ANYARCH | rpm.RPMSPEC_FORCE)
  File "specfile/spec_parser.py", line 228, in get_rpm_spec
    raise RPMException(stderr=stderr) from e

[nforro]

This is expected, parsing a spec file that expects the %fedora macro to exist on CentOS Stream 9 won't work. It is necessary to either define the macro to some value in parse_time_macros or fix the spec file, for example by changing %{fedora} >= 39 to 0%{?fedora} >= 39.

[xsuchy]

There is 87 such cases in Fedora. :(

[xsuchy]

IMO, as a long-term solution, we should either workaround the TB and at least partially parse it (not ideal) or evaluate the spec file in an environment where macros are defined from a particular chroot (ideal, but hard to implement).

[nforro]

There is 87 such cases in Fedora. :(

Well, technically there is nothing wrong with it if the spec file is Fedora-only.

IMO, as a long-term solution, we should either workaround the TB and at least partially parse it (not ideal) or evaluate the spec file in an environment where macros are defined from a particular chroot (ideal, but hard to implement).

It should be possible to use macro files from Fedora (we could have them in our base image for example), but we would have to keep them up-to-date somehow. Or we could simply have parse_time_macros define %fedora to 0 by default to solve this particular case.

[xsuchy]

It should be possible to use macro files from Fedora (we could have them in our base image for example), but we would have to keep them up-to-date somehow. Or we could simply have parse_time_macros define %fedora to 0 by default to solve this particular case.

And %rhel for RHEL/CENTOS and %suse for opensuse... we will never be able to catch up. This has to be a general solution.

[nforro]

Let's solve this specific case by defining the %fedora macro to 0. I will open a follow-up issue to handle this problem in a more general way.