From Fedora Project Wiki

Revision as of 19:58, 21 February 2009 by Laubersm (talk | contribs) (PackagingDrafts/SpecFileNaming moved to Archive:PackagingDrafts/SpecFileNaming: Appears to be included in Packaging:NamingGuidelines#Spec_file_name)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Spec File Naming

Draft: 0.1

This text will appear on: and be linked from:

It was discussed in this review bug:


The name of a spec file currently has to match the name of the generated package. This is for two reasons: 1. Preserve history of changes to a spec file in the revision control system. 2. Make it easy for someone extracting an rpm to know what spec filename they need to look for.

During the Core merge, some packages which are presently using the %{name}%{version}.spec format will lose history if forced to change. This change provides a temporary exception for those packages.

Text of Change

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.


If your package is named foo-1.0.0-1.src.rpm, then the spec file should be named foo.spec.

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.

As a special exception, there are a few packages which are allowed to have a version in their spec filename. This is because they had the version in their name when they were merged from Fedora Core's cvs and removing the version at that time would *lose* history:

  • gcc
  • [Please ask the packaging committee to add your package if you think it should also fall under this exception.]

This exception will go away when any of the following criteria are met: 1. We move the packages to a revision control system which is able to preserve history across a file rename. 1. The package spec file is going to be renamed anyway (for example, gcc41.spec is imported into cvs. When gcc is upgraded to gcc-4.2, the new spec will be created as gcc.spec not gcc42.spec)