This should be a switch, not the default behavior. Other distributions use these tools and use the classical layout (e.g. CentOS and Mageia).

Ah, OK. I can do that. I was also wondering if a script in fedora-packager would be more appropriate since that is fedora specific?

It probably would be, but is fedora-packager still alive?

Looks like it: https://pagure.io/fedora-packager

The package is available, even on F31:
https://koji.fedoraproject.org/koji/packageinfo?packageID=5409

I added an option now so users can choose the new layout if they want. The default is to use the traditional layout.

The harsh reality is that if it's an option then practically nobody will use it, so it wont bring us any closer to the long-term goal. Just saying.

I'd also suggest that people actually tests the suggested configuration in personal use for some time before pushing into rpmdevtools. I don't use that setup myself, haven't even tried it in that exact form, I only provided it on the ml as an example of how one might go about configuring rpm to better match the fedpkg experience.

Other distributions use these tools and use the classical layout (e.g. CentOS and Mageia).

I am not sure what you mean by this? How would CentOS use this tool? CentOS is using Koji and Mock to build packages and there is no rpmdev-setuptree used. The same applies to RHEL. So there cannot be any harm done.

If this gets into Fedora and subsequently into next RHEL, then some documentation [1] would need to be adjusted. But that cannot be showstopper.

I have no idea how this tool is used by Mageia.

I was wondering if proposing this as a Change for F32 would get it the visibility it deserves? If that's a good idea, then I can propose the change etc.

The harsh reality is that if it's an option then practically nobody will use it, so it wont bring us any closer to the long-term goal. Just saying.

At least as far as Fedora is concerned, we'll update the docs where rpmdev-setuptree is used to get more people to move to this.

I'd also suggest that people actually tests the suggested configuration in personal use for some time before pushing into rpmdevtools. I don't use that setup myself, haven't even tried it in that exact form, I only provided it on the ml as an example of how one might go about configuring rpm to better match the fedpkg experience.

+1, I've moved to it now. Seems fine at the moment.

Can we consider doing this again, at least for new setups? Having two different ways of doing things (~/rpmbuild directory tree and "flat" dist-git repos) is confusing to newcomers. I can't tell what this PR did, because the branch is gone, but using macros like these is very nice:

%_topdir        %(pwd)
%_rpmtopdir     %{_topdir}
%_builddir      %{_rpmtopdir}
%_buildrootdir  %{_rpmtopdir}
%_sourcedir     %{_rpmtopdir}
%_specdir       %{_rpmtopdir}
%_rpmdir        %{_rpmtopdir}
%_srcrpmdir     %{_rpmtopdir}

This makes sense in fedpkg rather than rpmdevtools, since the former is opinionated and specifically supports Dist-Git (which is not a real thing from an rpm perspective).

Plus, making rpmdev-setuptree do this would create a footgun in which by default you'd get people accidentally clobbering things.

I fail to see clobbering being much of a risk with the typical rpm contents, and it's at least as much of a risk in the traditional layout.

The traditional SPECS/SOURCES/RPMS etc layout is like any bad habit: surprisingly hard to shake off. I've tried swapping to a dist-git like setup a couple of times now and keep having to revert to "good old" because of 15+ years of accumulated "stuff" in the directories and neural system :laughing:

Well, the difference is that setting %_topdir to %(pwd) means that gets written to wherever you're running it. That's fine if you know you're working in a git tree or some kind of packaging directory. That's less fine when you're working in your home directory and wind up doing something weird because of it.

Yes, but the chances of actual collisions are fairly low, really. The real problem is our expectation of that stuff going someplace else than current directory.

My own personal setup is ~/rpmbuild/%{name} for the topdir, because that makes it easy for me to track all the different things I'm working on.

I am willing to guess that the expectation of most people is that tools look for files in the current working directory, not in "magical" other places like $HOME/rpmbuild/SOURCES/. That might not be the setup you're using, but the default should match people's expectations, not punch them in the face.

If you're going to do that, there's no point in using rpmdev-setuptree at all anyway. fedpkg already sets up for Dist-Git style.

fedpkg doesn't set up anything, the layout used by it is only active for building with fedpkg itself. When you need to bypass fedpkg for one reason or another, it gets stupid and annoying when you have to fedpkg srpm; rpm -i foo.src.rpm; rpmbuild -bb ~/rpmbuild/SPECS/foo.spec