On Fri, Dec 18, 2020 at 12:51:49AM +0100, clime wrote:

This change proposal does affect users.  The User Experience section
needs to answer the following:

Well, the users here are still packagers here no? I thought the "User"
in the title means "end user" who shouldn't be affected by it. Maybe
Ben can clarify this.

It _is_ meant to refer to end users, but we have a lot of highly technical
end users and sysadmins who might want to download and build source RPMs. So
the answers to these questions seem like reasonable things to add.

They can use mock if the preprocessing will be enabled for the
respective chroots where it is enabled in Koji/Fedora.
They can't directly use rpmbuild for those packages that contain the
macros. But they can use rpkg/fedpkg to do the work.
Or preprocess spec first and then use rpmbuild. I am aware this is a
negative point of this change.
While having an option to use rpmbuild directly to build srpm/rpm from
a dist-git repo is nice, I would say that fedpkg or mock are the main
interfaces to do this.
I know this answer won't satisfy everyone.

Not to mention the many folks who use Fedora .src.rpms as a starting point for EL-derivatives, or other RPM-based distros. Every time a Rawhide (or Fedora) SRPM fails to compile because of a non-backwards-compatible change, another frustrated sysadmin sheds a single tear.

Deprecating rpmbuild is a major change.

-jc