:thumbsup:

LGTM

I don't think you can deprecate the forge macros without deprecating the Go macros and the Font macros. They're very much tied together.

There are multiple developers who have submitted PRs to the forge macros, but the current redhat-rpm-config maintainers do not want to merge any changes made to them. There's been talk of splitting them out into separate package. I started working on splitting them out and writing unit tests in https://git.sr.ht/~gotmax23/forge-srpm-macros, but I'm not sure I want to commit to maintaining these in Fedora myself.

• https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/209
• https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/248

Since (based on those linked PR discussions) the situation with the macros is still evolving, at the risk of complicating things for the reader, perhaps the docs should briefly explain the current status instead of blanket declaring the macros deprecated? Something like,

[IMPORTANT]
.Status of the _"forge"_ macros
====
The current _"forge"_ macros
have been an unmaintained component of `+redhat-rpm-config+`
since 2018.
They have multiple issues
which may cause package builds to fail
or be built incorrectly.
They should currently **NOT** be used in new packages.
Discussions are underway,
with support from the `+redhat-rpm-config+` maintainers,
on splitting the _"forge"_ macros out into a separate package
so that they could be actively maintained,
and this restriction lifted.
See [somelink] for updates.
(This does not apply to Go or Fonts packages,            
where the _"forge"_ macros are only
an internal implementation detail.)
====

(Though I'd feel a lot better if "somelink" could be pointed to an actual issue or discussion about the proposed spinoff of the macros, rather than random hypotheticals in comments on random PRs.)

The middle paragraph could also be relegated to a footnote, if we don't want to blow out the size of the admonishment box quite so much.

I honestly don't like explaining things like "current status" because that's just something asking to be outdated when things change. If someone is going to work on the forge macros then great; if we're going to vote to deprecate them then we should do that and then actually ban their use for new packages.

Before we do anything, though, we should know what the current status is. Can anyone provide an update? I will happily yank them out of redhat-rpm-config and replacing them with a dependency once there's a package in the distro which actually provides them. I'll even review that package, if it helps.

We can't remove them, since they're an implementation detail of the Go and Fonts macros. However the %forge macros themselves no longer work nicely (or at all) with some recent Packaging changes - tilde, caret based versioning, rpmautospec, etc. - all of which are now the preferred way to handle their respective problems.

Simply put, if you're not doing Go or Fonts packages (you don't have a choice but to use them and deal with their idiosyncrasies in those cases), they conflict with other recently documented best practices.

As far as I can tell (the "History" view in pagure seems to be broken), the last change to "macros.forge" happened in May 2020. That commit only changed documentation though - the last actual code changes I could find happened in 2018 - over five years ago.

I seem to dully remember that @gotmax23 (sorry for tagging you if I remember wrong!) wanted to work on splitting the macros off from redhat-rpm-config into a separate package, but I don't know the status of that.

I merged a patch to add src.ht to the macros something like ten months ago. That was https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/209 which @gotmax23 linked above.

I still think the macros can be worked on. I understand enough to work on them in some fashion, though I doubt I could find the time to do anything significant. What keeps me from doing it (besides lack of time) is the fear that the entire Go stack breaks if I do something wrong. That's where some testing framework would really help, although even with it I don't know if adopting the more recent versioning framework is even possible. I guess that would take plenty of collaboration with Go maintainers.

Anyway, I would review and maybe even offer to co-maintain a package containing the forge macros. I just know I haven't the time to be a primary maintainer.

The problem is the creator of the macros forge fonts and golang has been
Mia for years, not responding to anything.

This is a problem for maintaining them, because we don't have anyone else
with expertise to update them. But we are dependent on them in Golang.

On Fri, 28 Jul 2023, 03:59 Jason =E3=83=86=E3=82=A3=E3=83=93=E3=83=84, pag= ure@pagure.io wrote:

tibbs commented on the pull-request: SourceURL: document that the forge" macros are deprecated / unmaintained that you are following:
``
I merged a patch to add src.ht to the macros something like ten months
ago. That was
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/209
which @gotmax23 linked above.

I still think the macros can be worked on. I understand enough to work o=
n
them in some fashion, though I doubt I could find the time to do anything
significant. What keeps me from doing it (besides lack of time) is the
fear that the entire Go stack breaks if I do something wrong. That's whe=
re
some testing framework would really help, although even with it I don't
know if adopting the more recent versioning framework is even possible. =
I
guess that would take plenty of collaboration with Go maintainers.

Anyway, I would review and maybe even offer to co-maintain a package
containing the forge macros. I just know I haven't the time to be a
primary maintainer.
``

To reply, visit the link below or just reply to this email
https://pagure.io/packaging-committee/pull-request/1270

A comment on https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/248 (the other, unmerged PR linked above) indicates @gotmax23 has created this repo of a proposed split-out forge macros package (with the change from that PR also merged, and tests added):

https://git.sr.ht/~gotmax23/forge-srpm-macros

I went through the issue tracker (https://todo.sr.ht/~gotmax23/forge-srpm-macros) and triaged the issues and added an initial specfile. I'll try to spend more time on it this over the weekend. I can add anyone who's interested in co-maintaining as a committer and/or issue triager. Issues tagged with mvp are things I'd like done before releasing v0.0.1.

The new forge-srpm-macros project now has support for Codeberg, nested Gitlab groups, a bunch of tests, and a new %forgeversion macro. You can test it with:

copr mock-config gotmax23/forge-srpm-macros-dev fedora-rawhide-x86_64 > ~/.config/mock/forge.cfg
fedpkg mockbuild --root forge --srpm-mock

or better yet, call mock directly, as fedpkg mockbuild --srpm-mock is a bit wonky

copr mock-config gotmax23/forge-srpm-macros-dev fedora-rawhide-x86_64 > ~/.config/mock/forge.cfg
fedpkg sources
mock --spec *.spec --source . -r forge

That Copr has a patched version of redhat-rpm-config that pulls in forge-srpm-macros.

I typed up a draft Change Proposal: https://fedoraproject.org/wiki/Changes/Reviatalize_Forge_Macros. Feedback welcome!

Since things are going in the direction of not deprecating anything, I'll go ahead and close this.