RPM Spec Wizard

Package names should be in lower case and use dashes in preference to underscores

For more information see Guidelines for Naming Fedora Packages .

Provide information about the upstream version of the packaged software to users.

Use an integer beginning with 1 and increasing for each revision of the package.
Put %{?dist} after the number.

For more information see Guidelines for Versioning Fedora Packages and an examples .

The summary should be a short and concise description of the package.

For more information see summary guidelines.

The description expands previously defined Summary. This can be one or few paragraphs. Do not include installation instructions in the description; it is not a manual. If the package requires some manual configuration or there are other important instructions to the user, refer the user to the documentation in the package. Add a README.Fedora, or similar, if you feel this is necessary.

For more information see description guidelines.

This field must be filled with the appropriate license Short Names(s) from the "Good License" tables on the Fedora Licensing page .

When your package is not licensed under one of "Good License" you can put here whatever you want. E.g., "Proprietary" or "Distributable", but you should really check that you are not violating upstream copyright.

Good start to check license of your package is to search sources for files like LICENSE, COPYING. Additionaly, you can use licensecheck (package licensecheck):
licensecheck $(find -type f)

For more information see Licensing Guidelines.

Link to the software homepage.

Link to the compressed archive of the upstream source code.

If needed, more SourceX directives can be added, incrementing the number each time.

This should point to an accessible and reliable storage of the archive, for example, the upstream page and not the packager’s local storage.

For more information see Source URL .

The name of the first patch to apply to the source code if necessary.

If needed, more PatchX directives can be added, incrementing the number each time.

For more information see Patch Guidelines.

If set to Automatic, the package automatically inherits the Architecture of the machine on which it is built, for example x86_64. If the package is not architecture dependent, for example, if written entirely in an interpreted programming language, set this to noarch.

For more information see Build on primary architecture .

A comma- or whitespace-separated list of packages required for building the program written in a compiled language.

There can be multiple entries of BuildRequires, each on its own line in the SPEC file.

For more information see Build Requires .

A comma- or whitespace-separated list of packages required by the software to run once installed.

There can be multiple entries of Requires, each on its own line in the SPEC file.

For more information see Explicit Requires .

If a piece of software can not operate on a specific processor architecture, you can exclude that architecture here.

For more information see Architecture build failures .

Command or series of commands to prepare the software to be built, for example, unpacking the archive in Source0. This directive can contain a shell script.

For more information see guidelines .

Command or series of commands for actually building the software into machine code (for compiled languages) or byte code (for some interpreted languages).

For more information see guidelines .

Command or series of commands for copying the desired build artifacts from the %builddir (where the build happens) to the %buildroot directory (which contains the directory structure with the files to be packaged). This usually means copying files from ~/rpmbuild/BUILD to ~/rpmbuild/BUILDROOT and creating the necessary directories in ~/rpmbuild/BUILDROOT. This is only run when creating a package, not when the end-user installs the package.

For more information see guidelines .

The list of files that will be installed in the end user’s system.

For more information see guidelines .

A record of changes that have happened to the package between different Version or Release builds.

For more information see guidelines .

RPM spec files have several sections which allow packages to run code on installation and removal. These bits of code are called scriptlets and are mostly used to update the running system with information from the package.

For more information see Fedora Packaging Guidelines for RPM Scriptlets .

All scriptlets are optional.

The %pretrans scriptlet will, in the particular case of system installation, run before anything at all has been installed. This implies that it cannot have any dependencies at all. Not even shell. For this reason, %pretrans is best avoided, but if used it MUST (by necessity) be written in Lua. See Lua in RPM for more information.

The %pre scriptlet executes just before the package is to be installed.

The %post scriptlet executes just after the package is to be installed.

The %preun scriptlet executes just before the package is to be erased.

The %postun scriptlet executes just after the package is to be erased.

The %posttrans scriptlet executes after all RPM package transactions.