forgeautosetup is utilized by almost 300 packages and is generally
useful for single-source specfiles — i.e., the large majority of cases —
so there are no plans to remove it.
For non-forge packages, the default in Fedora is to use `%autosetup` so
patches are automatically applied; it makes sense to adopt the same
practice for the forge macros.
I have made the decision to restore compatibility with EL 9 and pause
efforts in https://todo.sr.ht/~gotmax23/forge-srpm-macros/3 to continue
adopting new RPM 4.17+ features.
Packagers have requested the ability to use %forgeversion on EL 9, and
we need to support it for tools like Packit and Zuul CI that build SRPMs
in CentOS Stream containers to be able to adopt it.
Relates: https://todo.sr.ht/~gotmax23/forge-srpm-macros/3
We'll rely on this until we can drop support for RPM 4.16 and RHEL 9.
The function have similar behavior to the macros table in the way that
they handle undefined macros.
Support for specifying forge schemes for unrecognized forges was added
in 6bd567d2ea.
This changes the macro name used to define the forge scheme from
`%forge` to `%forgename` to avoid potential namespace conflicts.
6bd567d2ea was never released, so this
should not break any package in the wild.
Users may wish to use the forge macros with self-hosted forges. Instead
of having to hardcode every single forge mapping, this allows users to
choose a forge scheme themselves.
See the discussion in
https://pagure.io/packaging-committee/pull-request/1295.
Note that `fedora.zalias` sets %version0 to %version if the former is
not set, but this change makes sure that %version0 is preferred if the
macros are set differently.
GitLab allows one to create groups within groups up to 20 levels [1],
but we really don't need to check that. One can just take the last
part of the path and treat that as the repo, instead of assuming it's
always domain.tld/group/repo.
[1] https://docs.gitlab.com/ee/user/group/subgroups/index.html
