I thought that at some point we tightened up the spec naming to absolutely require that the specfile for package asdfg be called asdfg.spec. However, the current guidelines say:
The spec file should be named using the %{name}.spec scheme. This is to make it easier for people to find the appropriate spec when they install a src.rpm.
There is normally no need to include the %{version} in the spec file name. If you are packaging multiple versions of a package for simultaneous use, they should already reflect the version in the %{name}.spec scheme (refer to Multiple Packages with the same base name for details). In normal cases adding the version can cause the spec file's history to be lost when a package's version is upgraded.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Spec_file_name
On IRC today it was mentioned that fedpkg will look for any spec and pick the first one it finds (in os.istdir() order, so it's pretty much random). I'm thinking we should just tighten up the language here to say that you must call the spec %{name}.spec, and in addition move that section to the main guidelines.
Or am I missing something? If there's a valid reason for having a differently-named spec file, I can think of what it would be. This would allow fedpkg to tighten up its method for finding the spec file, which would in turn allow people to check in other files named *.spec (for local edits or different compilation options, for example) without fear of fedpkg picking the wrong one.
Proposed language:
The spec file '''must''' be named %{name}.spec. That is, if your package is named asdfg, the spec file must be named asdfg.spec.
%{name}.spec
asdfg
asdfg.spec
Placed in a section "Spec Naming" just before "Spec Legibility" in the main guidelines page.
To get %{name} you need to parse spec file. But to locate spec file you need to know %{name}. That introduces chicken-egg problem.
Secondly, in some use cases (non-Fedora, but in Copr) it's common to have spec files named differently than %{name}.spec. If fedpkg was ever modified to enforce proposed spec naming rules then it would break workflows for those (non-Fedora) packages.
There's not really a chicken-egg problem, since in the general case you use the name of the current directory and if that doesn't work fedpkg can just fall back to picking a spec at random. You do realize it chooses it at random, right? If you're depending somehow on which spec fedpkg will get, you're already broken.
I cannot possibly fathom why anyone would think the current behavior is a good idea, but in any case this isn't about fedpkg. It's about the guidelines saying what the spec file should be named.
And I have zero interest in non-fedora packages anyway. Broken is broken regardless, but we're talking about the '''Fedora''' packaging guidelines here.
It was pointed out on packaging@ that the review guidelines already mandate the proposed spec file naming. I'm not sure how that page came to be stricter than the actual guidelines but they need to be brought into agreement regardless. I suspect that at some point we tightened up the language but only updated the review guidelines for some reason.
Also, it occurred to me that fedpkg could easily get the package name (and hence the spec name) the same way it currently gets the default for --dist: from the git information it should already have. If it doesn't have the git info then it can fall back to the directory name and then the current "pick one at random" behavior.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-07-30/fpc.2015-07-30-16.00.txt):
I don't have a complete package set atm. ... but checking upto python* I have:
{{{ libglademm24 libglademm.spec libgnomecanvasmm26 libgnomecanvasmm.spec pylast python-pylast.spec }}}
The guideline on spec file naming was moved into the main guidelines and now requires that its name be constructed by taking the name of the source package and appending ".spec".
FWIW full package set only had a single extra package, and that looks like more of a mistake/accident than anything:
{{{ <package> <spec-filename> R-TH-data R-TH.data.spec libglademm24 libglademm.spec libgnomecanvasmm26 libgnomecanvasmm.spec pylast python-pylast.spec }}}
See also https://bugzilla.redhat.com/show_bug.cgi?id=1243546
Metadata Update from @tibbs: - Issue assigned to tibbs
Login to comment on this ticket.