Name tag isn't error-prone either. To be able to correctly do that one would need to recreate build root so all potential macros are defined as they can step in the name definition.

Actually, yeah, it might even make more sense to prefer the spec's Name tag.

This issue has been unresolved for more than a year, and is going to be closed within a week if no further action is taken. If you feel this is in error, please contact me.
This is a cleaning process suggested by Jay Greguske. Copy of this ticket was already closed in JIRA tracker.

This is still a problem, as far as I can tell, so I think the ticket should stay open. Using the package spec's %{name} property makes more sense to me in general, but using it as a fallback only in certain situations and not others seems like a bug.

There's a trickiness here, though — doesn't fedpkg also use the git URL to guess the name of the spec file itself? How can it prefer pulling the name from the spec file, when it has to first find the spec file from which to read the name?

(Sure, most repos only have a single .spec file in them, so we can assume it's that one. But since the name of the file can't be predetermined it's a bit chicken-and-egg to say "get the name from a file we don't actually know the name of yet".)

And there have, in fact, been many occasions when I've duplicated a spec file locally within some package directory to make changes, and either:

1. Been happy that fedpkg doesn't suddenly get confused into using the wrong spec file (my duplicate) just because it's now also sitting in the directory, or
2. Been frustrated because I want fedpkg to use a different spec file (my duplicate) for a local or mockbuild build, and there appears to be no way to convince it to do that short of overwriting the canonical one. (Well, I could maybe use rpmbuild to create an SRPM from my alternate spec file, then run a fedpkg --srpm <that_srpm> local. But I'm not even sure that would work right, if the spec file is named wrong.)

I guess what I'm getting at is, having the build configuration for <package> be canonically named <package>.spec seemed like a good idea when we thought we'd be keeping them all together in rpmbuild/SPECS/. But since we've embraced one-source-directory-per-package, having a standardized name for the build configuration like PKGBUILD or debian/control would've actually made life a lot easier in many ways.