The following format must be used:

  Source0: ftp://ftp.example.com/pub/foo/%{name}-%{version}.tar.gz

  Source1: ftp://ftp.example.com/pub/foo/%{name}-%{version}.tar.gz.asc

  Source2: https://www.example.com/gpgkey-0123456789ABCDEF0123456789ABCDEF.gpg

  …

  %prep

  %{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}' --data='%{SOURCE0}'

  The first source is the actual tarball,

  the second one is the signature from upstream,

  then the verification step must be adjusted accordingly,

  for example:

  Source0: ftp://ftp.example.com/pub/foo/%{name}-%{version}.tar.xz

  Source1: ftp://ftp.example.com/pub/foo/%{name}-%{version}.tar.asc

  Source2: https://www.example.com/gpgkey-0123456789ABCDEF0123456789ABCDEF.gpg

  …

  %prep

  xzcat '%{SOURCE0}' | %{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}' --data=-

  Packages that are vital during bootstrapping of Fedora

  may use a <<bootstrapping,bootstrap flag>>

  and the repositories to which the built noarch package will be added,

  by using either the `+ExcludeArch:+` or `+ExclusiveArch:+` tags:

  BuildArch: noarch

  # List the arches that the dependent package builds on below

  ExclusiveArch: %{ix86} %{arm} x86_64 noarch

  Sometimes a language runtime you are packaging for will provide a macro

  for the arches it's available on, for instance,

  which are conditionalized on architecture.

  For example, this is forbidden:

  %ifarch ppc64

  Patch0: build-fix-for-ppc64.patch

  %endif

  Conditionalizing `+Source:+` or `+Patch:+` tags by architecture

  causes the contents of the source package to differ

  using `+%ifarch+` or `+%ifnarch+` as appropriate.

  For example:

  %prep

  %setup -q

  %ifarch s390x

  %patch0 -p1

  %endif

  == Filesystem Layout

  they work according to the path specified in the rpm `+%files+` section.

  So an rpm which specified:

  %files

  /bin/sh

  would be able to satisfy a file dependency for `+/bin/sh+`

  but not for `+/usr/bin/sh+`.

  you can use a Virtual Provides to list the alternate path.

  For instance:

  Provides: %{_sbindir}/ifconfig

  [...]

  %files

  /sbin/ifconfig

  If you are a packager who uses file dependencies

  to Require the proper dependencies

  to the package name.

  For example:

  Requires: foo

  becomes:

  Requires: foo%{?_isa}

  If the foo-devel package has a foo-config script,

  you can try doing a foo-config --libs and foo-config --cflags

  (unless the packages involved are noarch)

  and there should be a spec file comment justifying it:

  # The automatic dependency on libfubar.so.1 is insufficient,

  # as we strictly need at least the release that fixes two segfaults.

  Requires: libfubar%{?_isa} >= 0:1.2.3-7

  Packagers should revisit an explicit dependency

  as appropriate to avoid it becoming inaccurate and superfluous.

  but SRPMs need to be architecture independent.

  For instance, if you did this:

  # Example of what *not* to do

  BuildRequires:  foo%{?_isa} >= 3.3

  Then the SRPM that is built in Fedora would have one of these Requirements

  depending on what builder the SRPM was created on:

  If a particular change is related to a Bugzilla bug,

  include the bug ID in the changelog entry for easy reference, e.g.

  * Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 1.0-2

  - Added README file (#42).

  You must use one of the following formats:

  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4

  - And fix the link syntax.

  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4

  - And fix the link syntax.

  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>

  - 0.6-4

  - And fix the link syntax.

  Changelog entries should provide a brief summary

  of the changes done to the package between releases,

  In this situation, you have added this changelog entry,

  but have not built the package yet:

  * Nov 12 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1

  - Fix spelling errors in package description

  The next day, you make additional changes to the spec,

  and need to add a new changelog line,

  then you would update the existing date line for 1.0-1,

  and append any new notes, making the changelog look like this:

  * Nov 13 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1

  - Fix spelling errors in package description

  - Add a patch to fix compilation problems on F15

  Please remember that this is only acceptable if 1.0-1 has not yet been built.

  In this situation, you have added this changelog entry,

  but have not built the package yet:

  * Nov 12 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1

  - Fix spelling errors in package description

  The next day, you make additional changes to the spec,

  and need to add a new changelog line.

  Now, you can add an additional changelog item with the new date,

  but the same Version-Release, so your new changelog looks like this:

  * Nov 13 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1

  - Add a patch to fix compilation problems on F15

  * Nov 12 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1

  - Fix spelling errors in package description

  Please remember that this is only acceptable if 1.0-1 has not yet been built.

  So the `+%files+` section MUST reference manpages

  with a pattern that takes this into account:

  %files

  %{_mandir}/man1/foo.1*

  Note also that files installed in `+%{_mandir}+`

  are automatically marked by RPM as documentation.

  If clang is being used to build a package,

  packagers must set the %toolchain macro to clang:

  %global toolchain clang

  This ensures that Fedora's clang-specific compiler flags are used

  when compiling.

  to make it easier to switch between two different compilers,

  then the following macros names should be used:

  %bcond_with toolchain_clang

  %bcond_with toolchain_gcc

  Packagers may also use the %build_cc, %build_cxx, or %build_cpp macros

  in the spec file in place of hard-coding the compiler name.

  In Fedora, PIE is enabled by default. To disable it in your

  spec, add:

  %undefine _hardened_build

  If your package meets any of the following criteria you

  MUST NOT disable the PIE compiler flags:

  it must do so using a fully versioned arch-specific

  (for non-noarch packages) dependency:

  Requires: %{name}%{?_isa} = %{version}-%{release}

  == Shared Libraries

  you MAY place all the static library files in the _*-devel_ subpackage.

  When doing this you also MUST have a virtual Provide

  for the _*-static_ package:

  %package devel

  Provides: foo-static = %{version}-%{release}

  Packages which explicitly need to link against the static version

  MUST `+BuildRequire: foo-static+`,

  Place all of the header files in the _*-devel_ subpackage

  and then you must have a virtual Provide for the _*-static_ package:

  %package devel

  Provides: foo-static = %{version}-%{release}

  Packages which use the header library must `+BuildRequire: foo-static+`,

  so that the usage can be tracked.

  It is a good idea to add it to the `+%__arch_install_post+` macro

  in your `+~/.rpmmacros+` config file:

  /usr/lib/rpm/check-rpaths     \

  /usr/lib/rpm/check-buildroot

  When _check-rpaths_ is run, you might see output like this:

  * If the application uses a local copy of libtool,

  add the following lines to the spec after %configure:

  %configure

  sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool

  sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool

  * Sometimes, the code/Makefiles can be patched

  to remove the _-rpath_ or _-R_ flag from being called.

  if the .desktop file's content/location does not need modification.

  Here are some examples of usage:

  desktop-file-install                                    \

  --dir=%{buildroot}%{_datadir}/applications              \

  %{SOURCE3}

  desktop-file-install                                    \

  --add-category="AudioVideo"                             \

  --delete-original                                       \

  --dir=%{buildroot}%{_datadir}/applications              \

  %{buildroot}/%{_datadir}/applications/foo.desktop

  desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop

  Do *not* apply a vendor tag to .desktop files (using --vendor).

  If the package uses gettext for translations, add

  BuildRequires: gettext

  For Qt-based packages that use the Linguist tool chain,

  for the localization utilities add

  BuildRequires: qt-devel

  If you have few enough locale files that they can all go into one package,

  you can use the `+%find_lang+` macro.

  after all of the files have been installed into the buildroot.

  The correct syntax for `+%find_lang+` is usually:

  %find_lang %{name}

  In some cases, the application may use a different "name" for its locales.

  You may have to look at the locale files and see what they are named.

  to include the locales detected by `+%find_lang+`.

  To do this, you should include it with the -f parameter to `+%files+`.

  %files -f %{name}.lang

  %{_bindir}/foobar

  ...

  Note that `+%find_lang+` by default searches for gettext locales,

  but it can also handle Qt translations, localised manpages and help files.

  To process GNOME help files put into `+/usr/share/gnome/help/+` use

  %find_lang %{name} --with-gnome

  To process KDE help files put into `+/usr/share/doc/HTML/+` use

  %find_lang %{name} --with-kde

  To process Qt's `+.qm+` binary translation files use

  %find_lang %{name} --with-qt

  To process localised manpages

  (doesn't include the default, non-localised one), use

  %find_lang %{name} --with-man

  To see all the options, run `+/usr/lib/rpm/find-lang.sh+` in the terminal.

  in `+foo.spec+` with the "foo" application localised

  using gettext and man pages named "bar" instead of "foo":

  Name: foo

  ...

  %prep

  * Thu May 4 2006 Tom "spot" Callaway <tcallawa@redhat.com> 0.1-1

  - sample spec that uses %%find_lang

  === Why do we need to use %find_lang?

  * Most packages that have locales have lots of locales.

  Using `+%find_lang+` is much easier in the spec file than having to do:

  %{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo

  %{_datadir}/locale/be/LC_MESSAGES/%{name}.mo

  %{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo

  %{_datadir}/locale/de/LC_MESSAGES/%{name}.mo

  %{_datadir}/locale/es/LC_MESSAGES/%{name}.mo

  ...

  * As new locale files appear in later package revisions,

  `+%find_lang+` will automatically include them when it is run,

  Whenever possible, invocations of `+make+` should be done as

  %make_build

  This generally speeds up builds and especially on SMP machines.

  as some make files do not support parallel building.

  Therefore you should consider adding

  %_smp_mflags -j3

  to your `+~/.rpmmacros+` file -- even on UP machines --

  as this will expose most of these errors.

  and include a link to that in the comment above the patch.

  For example:

  # https://bugzilla.gnome.org/show_bug.cgi?id=12345

  Patch: gnome-panel-fix-frobnicator.patch

  The above is perfectly acceptable;

  but if you prefer,

  a brief comment about what the patch does above can be helpful:

  # Don't crash with frobnicator applet

  # https://bugzilla.gnome.org/show_bug.cgi?id=12345

  Patch: gnome-panel-fix-frobnicator.patch

  Sending patches upstream and adding this comment

  will help ensure that Fedora is acting as a good FLOSS citizen

  You can indicate that you have sent the patch upstream and any known status:

  # Sent upstream via email 20080407

  Patch: foobar-fix-the-bar.patch

  # Upstream has applied this in SVN trunk

  Patch: foobar-fix-the-baz.patch

  ==== Fedora-specific (or rejected upstream) patches

  It may be that some patches truly are Fedora-specific; in that case, say so:

  # This patch is temporary until we land the long term System.loadLibrary fix in OpenJDK

  Patch: jna-jni-path.patch

  === Applying Patches

  Example:

  Version: 1.2

  Release: 3%{?dist}

  Epoch: 1

  A package with those definitions would be considered greater than

  a package with a higher version or a higher release.

  For example, if a package being depended upon has an Epoch,

  this must be listed when adding a versioned dependency:

  Requires: foo = %{epoch}:%{version}-%{release}

  === Epochs from Third Party Repositories

  into %\{_sysctldir} (/usr/lib/sysctl.d/)

  you must invoke %sysctl_apply in your %post section:

  %sysctl_apply foobar.conf

  If you install a binfmt configuration snippet waldo.conf

  into %\{_binfmtdir} (/usr/lib/binfmt.d/)

  you must invoke %binfmt_apply in your %post section:

  %binfmt_apply waldo.conf

  These have the effect of making the appropriate changes

  immediately upon package installation

  that are commonly found in version upgrade changes),

  provide clean upgrade paths and compatibility with:

  Provides: oldpackagename = $provEVR

  Obsoletes: oldpackagename < $obsEVR

  $provEVR refers to an (Epoch-)Version-Release tuple

  the original unchanged package would have had

  The following should be added to bar

  (and similarly for all subpackages as applicable):

  Provides: foo = 2:%{version}-%{release}

  Obsoletes: foo <= 2:1.0-4   # Important: We set the Obsoletes release to 4 to be higher than the previous Release: 3%{?dist}

  Explicit `+Provides:+` need to be aware of whether

  the package is supplying things that can be used in an arch-independent

  If your package introduces build time circular dependencies,

  you should use this macro to bootstrap your package:

  # When we are bootstrapping, we drop some dependencies, and/or build time tests.

  %bcond_with bootstrap

  %check

  make check

  %endif

  TIP: Since Fedora 30,

       as a nice side-effect,

  that is missing when bootstrapped,

  then that `+Provides:+` should look like:

  %if %{without bootstrap}

  Provides: bar(some_functionality)

  %endif

  Please note that usage of pre-built binaries

  in bootstrap still needs an exception from the Packaging Committee

  simply by defining the corresponding variable to `+%{nil}+`.

  For example, to disable the brp-python-bytecompile script:

  # Turn off Python bytecode compilation because this is a Jython

  # package and we will generate JVM bytecode instead

  %global __brp_python_bytecompile %{nil}

  Any package that disables a BRP script this way MUST also note the reason

  in an accompanying comment.