Diretrizes de Empacotamento do Fedora

Em geral, estas diretrizes se aplicam às versões atualmente lançadas e sem fim de vida útil do Fedora, bem como à versão de desenvolvimento do Fedora (Rawhide). Se uma parte específica destas diretrizes for relevante apenas para um subconjunto dessas versões, isso será especificamente observado. No entanto, observe que o Rawhide pode mudar rapidamente e haverá momentos em que as mudanças serão visíveis lá e ainda não foram refletidas aqui.

As diretrizes também cobrem, até certo ponto, pacotes para EPEL, mas apenas quando combinadas com as Diretrizes de empacotamento EPEL. O pacote Fedora muda muito mais rapidamente do que o pacote EPEL, portanto, com o tempo, essas diretrizes se afastarão ainda mais de qualquer versão EPEL específica e, para a versão EPEL mais antiga e suportada, as diferenças podem ser bastante significativas. As partes destas diretrizes que não se aplicam à EPEL geralmente não serão indicadas.

Como estas diretrizes nunca poderão cobrir todas as contingências possíveis, existirão sempre pacotes que necessitam de exceções. É responsabilidade do empacotador seguir estas diretrizes tão fielmente quanto possível e documentar claramente, como comentários no arquivo spec do pacote, os casos em que elas não possam ser seguidas.

Se, em uma diretriz, for usada a expressão “é recomendado” ou “é sugerido” e não for viável que o pacote esteja em conformidade com essa diretriz, o empacotador pode desviar-se dela. A natureza do desvio e o raciocínio por trás dele DEVEM ser documentados no arquivo spec.

Quando a linguagem “deve”, “é necessário” ou “precisa” for usada, o empacotador pode desviar-se da diretriz somente com a aprovação do comitê de empacotamento. Por favor, siga o procedimento na página do Comitê de Empacotamento para fazer essas solicitações.

Por favor, revise O que pode ser empacotado para garantir que o que você pretende empacotar é permitido no Fedora.

Recomenda-se que você siga as Diretrizes de nomenclatura para garantir que seu pacote seja nomeado apropriadamente.

A documentação que cobre a maneira correta de usar os campos Version e Release pode ser encontrada aqui.

Recomenda-se que você revise as informações sobre licenças determinadas como permitidas no Fedora e Diretrizes de licenças para garantir que seu pacote tenha as licenças corretas e estas sejam indicadas corretamente.

Muitas diretrizes específicas de idioma ou domínio referem-se a "bibliotecas", "módulos", "plug-ins" ou outros termos específicos do idioma ou domínio. Isto é especificamente importante para a nomenclatura de pacotes. Alguns aplicativos podem incluir bibliotecas e algumas bibliotecas podem incluir aplicativos, portanto a distinção nem sempre é clara.

É RECOMENDADO que os pacotes sejam instaláveis de forma independente sempre que isso for tecnicamente viável, mas eles DEVEM especificar dependências do tipo correto em outros pacotes, se necessário, veja Tipos de dependência abaixo.

Os aplicativos de desktop NÃO DEVEM depender de outros aplicativos de desktop, a menos que seja estritamente necessário. Em particular, pacotes que contêm um arquivo .desktop visível (um arquivo .desktop que não contém a linha NoDisplay=true) NÃO DEVEM ter um Requires, Recommends ou Supplements em qualquer outro pacote que contenha um arquivo de desktop visível, direta ou indiretamente.

Por exemplo, seria razoável que um editor de níveis de videogame exigisse o videogame associado para funcionar, ou que um plug-in de aplicativo exigisse o aplicativo associado. Mas não seria razoável que um aplicativo que usasse uma biblioteca de banco de dados dependesse de um conjunto de gerenciamento de banco de dados associado a essa biblioteca, ou que uma aplicação que usasse uma linguagem de programação específica dependesse de ferramentas de gerenciamento associadas a essa linguagem de programação.

Se um pacote fonte fornece múltiplas aplicações gráficas, essas aplicativos DEVEM ser empacotados em subpacotes separados quando possível.

O arquivo spec ("spec") é um elemento fundamental no fluxo de trabalho de empacotamento. Qualquer alteração feita no pacote incluirá uma alteração nas especificações. Como os pacotes no Fedora são mantidos por uma comunidade de empacotadores e também por ferramentas automatizadas, é importante que as especificações sigam certas convenções. A maior parte dessas diretrizes de empacotamento envolve o que consta nas especificações, mas aqui estão alguns itens gerais.

Nos casos em que o projeto upstream publica assinaturas OpenPGP de seus lançamentos, É RECOMENDADO que os pacotes Fedora verifiquem essa assinatura como parte do processo de construção do RPM.

Embora uma soma de verificação no arquivo-fonte certifique que um arquivo recuperado do cache lookaside é aquele que o empacotador carregou, ela não informa se o arquivo é o que o projeto upstream lançou. Uma assinatura dos desenvolvedores originais certifica que a fonte é idêntica à que eles lançaram. A verificação da assinatura como parte da construção garante que os empacotadores não se esqueçam de verificá-la.

Todos os pacotes do Fedora devem ser compilados e construídos com sucesso em rpms binários em pelo menos uma arquitetura primária suportada, exceto quando o pacote for útil apenas em uma arquitetura secundária (como um utilitário de inicialização específico da arquitetura, carregador de microcódigo ou ferramenta de configuração de hardware). É recomendado que os empacotadores do Fedora façam todos os esforços para suportar todas as arquiteturas primárias.

Conteúdo, código que não precisa ser compilado e construído, e código independente de arquitetura (noarch) são exceções notáveis.

O Fedora segue o Filesystem Hierarchy Standard (em português, Padrão de Hierarquia do Sistema de Arquivos) no que diz respeito ao layout do sistema de arquivos, com exceções indicadas abaixo. O FHS define onde os arquivos devem ser colocados no sistema.

Execute o rpmlint em rpms binários e fonte para examiná-los em busca de erros comuns e corrigi-los (a menos que o rpmlint esteja errado, o que também pode acontecer). Se você achar a saída do rpmlint enigmática, a opção -e pode ser usada para obter descrições mais detalhadas da maioria dos erros e avisos. Observe que o rpmlint realizará verificações adicionais se receber o nome de um pacote instalado. Por exemplo, dnf install foo-1.0-1.f20.x86_64.rpm; rpmlint -i foo executará um conjunto de testes no pacote foo que rpmlint foo-1.0-1.f20.x86_64.rpm não pode. Uma página mantida pela comunidade sobre problemas de rpmlint pode ser encontrada aqui.

Todas as dependências de pacotes (tempo de construção ou tempo de execução, regulares, fracas ou outras) DEVEM SEMPRE ser satisfeitas nos repositórios oficiais do Fedora.

O RPM pode determinar automaticamente dependências para a maioria das bibliotecas compiladas e para algumas linguagens de script como Perl. Dependências determinadas automaticamente NÃO DEVEM ser duplicadas por dependências manuais.

As dependências de compilação, no entanto, DEVEM ser listadas explicitamente, a menos que você esteja usando um gerador automático de dependência de compilação (por exemplo, Rust ou Python). Consulte Build-Time Dependencies (BuildRequires).

Para dependências versionadas (tempo de construção ou tempo de execução), É RECOMENDADO que sejam usadas APENAS quando realmente necessárias para garantir que a versão adequada de um pacote esteja presente. Se uma dependência versionada for satisfeita por uma versão presente em três versões anteriores do Fedora então uma dependência versionada não é necessária e o uso de uma dependência regular não versionada É RECOMENDADA em seu lugar.

Uma dependência versionada em um pacote com uma época definida DEVE ser incluída nessa dependência. Caso contrário, a dependência não funcionará conforme o esperado.

It is important that your package list all necessary build dependencies using the BuildRequires: tag. You MAY assume that enough of an environment exists for RPM to function, to build packages and execute basic shell scripts, but you SHOULD NOT assume any other packages are present as RPM dependencies and anything brought into the buildroot by the build system can change over time.

Se o arquivo spec contém dependências condicionais selecionadas com base na presença de argumentos opcionais --with(out) foo para rpmbuild, construa o RPM fonte a ser enviado com as opções padrão, ou seja, para que nenhum desses argumentos estão presentes na linha de comando rpmbuild. A razão é que esses requisitos são "serializados" no RPM fonte resultante, ou seja, as condicionais não se aplicam mais.

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

Any relevant documentation included in the source distribution should be included in the package in the proper documentation directory. Irrelevant documentation includes build instructions, the omnipresent INSTALL file containing generic build instructions, or example, and documentation for non-Linux systems, e.g. README.MSDOS. Also pay attention about which subpackage you include documentation in. For example API documentation belongs in the -devel subpackage, not the main one. Or if there’s a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use *-doc as the subpackage name.

Marking a relative path with %doc in the %files section will cause RPM to copy the referenced file or directory from %_builddir to the proper location for documentation. Files can also be placed in %_pkgdocdir, and the build scripts of the software being packaged may do this automatically when called in %install. However, mixing these methods is problematic and may result in duplicated or conflicting files, so use of %doc with relative paths and installation of files directly into %_pkgdocdir in the same source package is forbidden.

Files marked as documentation must not cause the package to pull in more dependencies than it would without the documentation. One simple way to ensure this in most cases is to remove all executable permissions from files in %_pkgdocdir.

Files located in %_pkgdocdir must not affect the runtime of the packaged software. The software must function properly and with unchanged functionality if those files are modified, removed or not installed at all.

Although license files are documentation, they are treated specially (including using a different tag). Please see Licensing Guidelines for how to handle them.

The changelog describes the changes to the package that are relevant to the users of the package. This includes new upstream versions, important changes to how the package is built, rebuilds, and other changes affecting the outcome. Changes which are only relevant to packagers should not be mentioned in the changelog. This includes spec file cleanups, build error fixes or workarounds, and other changes which don’t have an effect on content of the binary packages.

The changelog should be generated automatically from git commit logs using the %autochangelog macro:

The commit subject (the first line of the commit message) and optionally some additional lines are used to generate the changelog text. The commit author name and email address and the commit timestamp are also used in changelog entry.

The text in the the commit message which will become part of the changelog should provide a brief summary of the changes relevant for the user. The commit message may contain additional information that is relevant to packagers.

If a particular change is related to a Bugzilla bug, include the bug ID in the changelog entry for easy reference, e.g.

If a particular commit fixes a CVE, this information should be included too.

The intent is to give the user a hint as to what changed in a package update without overwhelming them with the technical details. They must never simply contain an entire copy of the source CHANGELOG entries. Links to upstream NEWS files or changelogs can be entered for those who want additional information.

See autochangelog documentation for the details of how the changelog is generated from git commit messages, and how to create multi-line entries or skip entries for certain commits.

Packagers may alternatively use a manual changelog instead of the %autochangelog macro. This is described in Manual Changelog.

As man pages are the traditional method of getting help on a Unix system, packages SHOULD contain them for all executables. If some man pages are absent, packagers SHOULD work with upstream to add them. It is also occasionally possible to find pages created by other distributions, or to use the output of the help2man program; those are often useful as a starting point. When installing man pages, note that RPM will re-compress them into its preferred format. So the %files section MUST reference manpages with a pattern that takes this into account:

Note also that files installed in %{_mandir} are automatically marked by RPM as documentation. Thus it is not necessary to use %doc.

For localised manpages, use %find_lang --with-man as described in Handling Locale Files.

Fedora packages should default to using gcc as the compiler (for all languages that gcc supports) or clang if upstream does not support building with gcc. However, if there is a good technical reason, packagers may choose not to use the default compiler. Examples of valid technical reasons to not use the default compiler, include but are not limited to:

Packagers choosing to use a non-default compiler should document the reason for this decision in a comment in the spec file.

If clang is being used to build a package, packagers must set the %toolchain macro to clang:

This ensures that Fedora’s clang-specific compiler flags are used when compiling.

If a packager wants to use conditional macros in a spec file to make it easier to switch between two different compilers, then the following macros names should be used:

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. The values of these variables are controled by setting the %toolchain macro to either clang or gcc.

Compilers used to build packages must honor the applicable compiler flags set in the system rpm configuration. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build.

For C, C++, and Fortran code, the %{optflags} macro contains these flags. Overriding these flags for performance optimizations (for instance, -O3 instead of -O2) is generally discouraged. If you can present benchmarks that show a significant speedup for this particular code, this could be revisited on a case-by-case basis. Adding to and overriding or filtering parts of these flags is permitted if there’s a good reason to do so; the rationale for doing so must be documented in the specfile.

There are certain, security related flags that are commonly allowed. These flags may degrade performance slightly but the increased security can be worthwhile for some programs.

Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one, but rpmbuild would do it anyway. Whenever a -debuginfo package is explicitly disabled, an explanation why it was done is required in the specfile. Debuginfo packages are discussed in more detail in a separate document, Packaging:Debuginfo.

Fedora packages must be designed with a logical separation of files. Specifically, -devel packages must be used to contain files which are intended solely for development or needed only at build-time. This is done to minimize the install footprint for users. There are some types of files which almost always belong in a -devel package:

The versioned shared library files (/usr/lib/libfoo.so.3.2.0 and /usr/lib/libfoo.so.3) are necessary for users to run programs linked against libfoo, so they belong in the base package. The other, unversioned, shared library file (/usr/lib/libfoo.so) is only used to actually link libfoo to code being compiled, and is not necessary to be installed on a users system. This means that it belongs in a -devel package. Please note that in most cases, only the fully versioned shared library file (/usr/lib/libfoo.so.3.2.0) is an actual file, all of the other files are symbolic links to it. When a shared library file is only provided in an unversioned format, the packager should ask upstream to consider providing a properly versioned library file. However, in such cases, if the shared library file is necessary for users to run programs linked against it, it must go into the base package. If upstream versions the shared library file at a future point, packagers must be careful to move to the versioned layout described above.

Subpackages are often extensions for their base package and in that case they should require their base package. When a subpackage requires the base package, it MUST do so using a fully versioned arch-specific (for non-noarch packages) dependency:

Devel packages are an example of a package that must require their base packages using a fully versioned dependency. -libs subpackages which only contain shared libraries do not normally need to explicitly depend on their base packages as they usually do not need the base package to be functional libraries.

If you end up in a situation where the main package depends on the subpackage and the subpackage on the main package you should think carefully about why you don’t have everything in the main package.

Whenever possible (and feasible), Fedora packages containing libraries SHOULD build them as shared libraries. It is not necessary to call ldconfig when installing shared libraries.

Packages including libraries SHOULD exclude static libs as far as possible (e.g., by configuring with --disable-static). Applications linking against libraries SHOULD link against shared libraries not static versions.

Libtool archives, foo.la files, SHOULD NOT be included. Packages using libtool will install these by default even if you configure with --disable-static, so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files SHOULD be treated as an API/ABI change — i.e., removing them changes the interface that the library gives to the rest of the world thus MUST follow Fedora policies for potentially destabilizing updates.

Fedora packages SHOULD make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.

All packages whose upstreams allow them to be built against system libraries MUST be built against system libraries. In this case, bundled libraries (and/or their source code) MUST be explicitly deleted during %prep. Build scripts may need to be patched to deal with this situation. Whenever possible, the patch should conditionalize the use of the bundled libraries, so that the patch can be sent upstream for consideration.

All packages whose upstreams have no mechanism to build against system libraries MAY opt to carry bundled libraries, but if they do, they MUST include an indication of what they bundle. This provides a mechanism for locating libraries with bundled code which can, for example, assist in locating packages which may have particular security vulnerabilities.

To indicate an instance of bundling, first determine the name and version of the bundled library:

Then at an appropriate place in your spec, add Provides: bundled(<libname>) = <version> where <libname> and <version> are the name and version you determined above. If it was not possible to determine a version, use Provides: bundled(<libname>) instead.

In addition to indicating bundling in this manner, packages whose upstreams have no mechanism to build against system libraries must be contacted publicly about a path to supporting system libraries. If upstream refuses, this must be recorded in the spec file, either in comments placed adjacent to the Provides: above, or in an additional file checked into the SCM and referenced by a comment placed adjacent to the Provides: above.

Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath. Normally, the dynamic linker and loader (ld.so) resolve the executable’s dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we usually do not permit the use of rpath in Fedora.

There is a tool called check-rpaths which is included in the rpmdevtools package. It is a good idea to add it to the %__arch_install_post macro in your ~/.rpmmacros config file:

When check-rpaths is run, you might see output like this:

Any rpath flagged by check-rpaths MUST be removed.

Configuration files must be marked as such in packages.

As a rule of thumb, use %config(noreplace) instead of plain %config unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files n package upgrades. An example case when not to use noreplace is when a package’s configuration file changes so that the new package revision wouldn’t work with the config file from the previous package revision. Whenever plain %config is used, add a brief comment to the specfile explaining why.

Don’t use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in Fedora.

In the Fedora.next world, we will have a set of curated Fedora Products as well as the availability of classic Fedora. Historically, we have maintained a single set of configuration defaults for all Fedora installs but different target use-cases have different needs. Please see the Per-Product Configuration Guidelines for instructions on how to create packages that need to behave differently between Fedora.next Products.

SystemV-style initscripts are forbidden in Fedora. Systemd units must be used instead.

Detailed guidelines for packaging systemd units and systemd-managed services are here.

If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws a window and runs from within that window. Installed .desktop files MUST follow the desktop-entry-spec, paying particular attention to validating correct usage of Name, GenericName, Categories, StartupNotify entries.

Packages containing graphical applications should include AppData files. See Packaging:AppData for the relevant guidelines.

Packagers are strongly encouraged to use macros instead of hard-coded directory names (see RPMMacros). However, in situations where the macro is longer than the path it represents, or situations where the packager feels it is cleaner to use the actual path, the packager is permitted to use the actual path instead of the macro. There are several caveats to this approach:

Macros with names beginning with underscores are generally considered to be implementation details internal to RPM and its associated macro packages and SHOULD NOT be referenced in specfiles except to set their values in order to influence RPM behavior. This implies that macro forms of system executables SHOULD NOT be used. For example, rm should be used in preference to %{__rm}. However, in some cases needed data are simply not provided under names which are not prefixed with underscores. If that is the case, the macro named with leading underscores MAY be used. Authors of macro packages are encouraged to avoid using leading underscores when naming macros which are intended to be used in specfiles (as opposed to being set).

Having macros in a Source: or Patch: line is a matter of style. Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used. In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid. spectool (from the rpmdevtools package) can aid you in checking that whether the URL contains macros or not.

If you need to determine the actual string when it contains macros, you can use rpm. For example, to determine the actual Source: value, you can run:

Sometimes it is necessary to write a short script (perhaps a one-liner) that is executed in the %prep, %build, or %install sections of a spec file to get some information about the build environment. In order to simplify the dependency graph, spec files should only use the following languages for this purpose:

Additionally, if your package cannot build without a specific scripting language (such as Ruby, or Tcl), and therefore already has a BuildRequires on that language, it may also be called from the spec file.

Note: If you call Perl or Python in your spec file (and it is not already a BuildRequires for the package), you need to explicitly add a BuildRequires for Perl or Python.

Use %global instead of %define, unless you really need only locally defined submacros within other macro definitions (a very rare case).

Rationale: The two macro defining statements behave the same when they are at the top level of rpm’s nesting level.

But when they are used in nested macro expansions (like in %{!?foo: ... } constructs, %define theoretically only lasts until the end brace (local scope), while %global definitions have global scope.

Note that %define and %global differ in more ways than just scope: the body of a %define’d macro is lazily expanded (i.e., when used), but the body of %global is expanded at definition time. It’s possible to use %%-escaping to force lazy expansion of %global.

Translation files may be handled by different programs for different frameworks. Make sure you add BuildRequires: for the correct package or else your package could fail to generate translation files in the buildroot.

If the package uses gettext for translations, add

For Qt-based packages that use the Linguist tool chain, for the localization utilities add the appropriate qtX-linguist package

If you have few enough locale files that they can all go into one package, you can use the %find_lang macro. (If you need to split your package into separate language packs, please see the langpack guidelines.) This macro will locate all of the them belonging to your package (by name), and put this list in a file. You can then use that file to include all of the locales. %find_lang should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for %find_lang is usually:

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. If they are named myapp.mo, then you will need to pass myapp to %find_lang instead of %{name}. After %find_lang is run, it will generate a file in the active directory (by default, the top level of the source dir). This file will be named based on what you passed as the option to the %find_lang macro. Usually, it will be named %{name}.lang. You should then use this file in the %files list to include the locales detected by %find_lang. To do this, you should include it with the -f parameter to %files.

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

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

To process Qt’s .qm binary translation files use

To process localised manpages (doesn’t include the default, non-localised one), use

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

Names different from %{name} (e.g. multiple manpages) must be handled via separate calls to %find_lang.

Here is an example of proper usage of %find_lang, in foo.spec with the "foo" application localised using gettext and man pages named "bar" instead of "foo":

Packages which generate log files should write out their logfiles in a package-specific (and package owned) directory under %{_localstatedir}/log. Unless the software being packaged rotates its own logs, it must also ship a logrotate config file to rotate its log file(s).

When adding file copying commands in the spec file, consider using a command that preserves the files' timestamps, e.g., cp -p or install -p.

When downloading sources, patches etc., consider using a client that preserves the upstream timestamps. For example wget -N or curl -R. To make the change global for wget, add this to your ~/.wgetrc: timestamping = on, and for curl, add to your ~/.curlrc: -R.

Whenever possible, invocations of make should be done as

This generally speeds up builds and especially on SMP machines.

Do make sure, however, that the package builds cleanly this way as some make files do not support parallel building. Therefore you should consider adding

to your ~/.rpmmacros file — even on UP machines — as this will expose most of these errors.

Great care should be taken when using scriptlets in Fedora packages. If scriptlets are used, those scriptlets must be sane. Some common scriptlets are documented here.

When building software, which you have not conducted a full security-audit on, protect sensitive data, such as your GPG private key, in a separate user account.

The same applies to reviewers/testers. Rebuild src.rpms in a separate account which does not have access to any sensitive data.

The use of RPM’s facility for generating relocatable packages is strongly discouraged. It is difficult to make work properly, impossible to use from the installer or from yum, and not generally necessary if other packaging guidelines are followed. However, in the unlikely event that you have a good reason to make a package relocatable, you MUST state this intent and reasoning in the request for package review.

Your package should own all of the files that are installed as part of the %install process.

In most cases, it should not be necessary for multiple packages to contain identical copies of the same file. However, if it is necessary, multiple packages may contain identical copies of the same file, as long as the following requirements are met:

OR

In addition, identical files are defined as files which are always identical in content, checksum, permissions, and location on the filesystem in each package.

One notable type of file that is often shared identically between subpackages is the license text. There are certain situations where it is required to duplicate the license text across multiple %files section within a package. For more details, please refer to Subpackage Licensing.

Directory ownership is a little more complex than file ownership. Packages must own all directories they put files in, except for:

In this context, a package’s "natural dependency chain" is defined as the set of packages necessary for that package to function normally. To be specific, you do not need to require a package for the sole fact that it happens to own a directory that your package places files in. If your package already requires that package for other reasons, then your package should not also own that directory.

In all cases we are guarding against unowned directories being present on a system. Please see Packaging:UnownedDirectories for the details.

Here are examples that describe how to handle most cases of directory ownership.

Some packages require or benefit from dedicated runtime user and/or group accounts. Guidelines for handling these cases are in a separate document.

Note that system services packaged for Fedora MUST NOT run as the nobody user, but MUST instead allocate their own system user.

Web applications packaged in Fedora should put their content into /usr/share/%{name} and NOT into /var/www/. This is done because:

Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora’s Conflicts policy, see: Conflicts.

Tools such as Alternatives and Environment Modules can also help prevent package conflicts.

RPM supports a field called "Epoch:", which is a numeric field, that, if set, adds another qualifier for RPM to use in doing package comparisons. Specifically, if set, the Epoch of a package trumps all other comparisons (except for a larger Epoch). If Epoch is not set in a package, RPM treats it the same as if it was set to 0.

Example:

A package with those definitions would be considered greater than a package with a higher version or a higher release. Since Epoch is confusing to humans (and can never be removed from a package once used), it should only be used in Fedora as a last resort to resolve upgrade ordering of a package, and should be avoided wherever possible.

Also, Epoch complicates normal packaging guidelines. If a package uses an Epoch, it must be referred to in any place where %{version}-%{release} is used. For example, if a package being depended upon has an Epoch, this must be listed when adding a versioned dependency:

There are two ways of making a symlink, either as a relative link or an absolute link. In Fedora, neither method is required. Packagers should use their best judgement when deciding which method of symlink creation is appropriate.

In some cases replacing a symlink to a directory requires special handling. Replacing a directory with any type of file always requires special handling.

See Packaging:Directory_Replacement for information about doing this.

If the source code of the package provides a test suite, it should be executed in the %check section, whenever it is practical to do so.

There are specific guidelines for handling tmpfiles.d configurations and directories (in /run and /run/lock): Tmpfiles.d.

In the event that it becomes necessary to rename or replace an existing package, the new package should make the change transparent to end users to the extent applicable.

If a package is being renamed without any functional changes, or is a compatible-enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with:

$provEVR refers to an (Epoch-)Version-Release tuple the original unchanged package would have had if it had been version or release bumped. You usually use macros here because the provides EVR should continue to go up as the renamed package advances in version and release. $obsEVR is an (Epoch-)Version-Release tuple arranged so that there is a clean upgrade path but without gratuitously polluting the version space upwards. You usually do not use macros for this as you’re simply trying to advance beyond the last known release under the old name.

If a package supersedes/replaces an existing package without being a sufficiently compatible replacement as defined above, use only the Obsoletes: line from the above example.

If retired packages need to be removed from end user machines because they cause dependency issues which interfere with upgrades or are otherwise harmful, a packager SHOULD request that Obsoletes: be added to fedora-obsolete-packages. Simply file a bugzilla ticket here. Please include information on which packages need to be obsoleted, the exact versions which need to be obsoleted, and the reasons why they cannot be allowed to remain installed.

If the obsoleted package had an Epoch set, it must be preserved in both the Provides: and Obsoletes:. For example, assume foo being renamed to bar, bar is compatible with foo, and the last foo package release being foo-1.0-3.fcNN with Epoch: 2. The following should be added to bar (and similarly for all subpackages as applicable):

Explicit Provides: need to be aware of whether the package is supplying things that can be used in an arch-independent or arch-specific fashion. For packages that are not noarch, Provides: should be made arch-specific by applying the %{?_isa} macro to the end of the text string in Provides (e.g. Provides: foo%{?_isa} = 2:%{version}-%{release}). Packages that explicitly provide things that can be used in an arch-independent way (for example, those whose dependents don’t need to be of the same arch) need not apply this macro. In some cases, a package will supply multiple elements, some of which may be consumed only by dependents of an identical arch and some which may be consumed by dependents of any arch. In such cases, both arch-specific and arch-independent Provides: are warranted.

Examples of packages that should explicitly provide only arch-specific Provides: include native code libraries or plug-ins and their associated -devel packages. Packages that should explicitly provide only arch-independent Provides: include most stand-alone programs (in addition to all noarch packages). Even though these programs may themselves be arch-specific, clients that run them should not care about their arch in most cases. A package that explicitly provides, for example, both a native code library as well as an interpreted language interface to that library should have both arch-specific (for clients of the native code library) and arch-independent (for clients of the interpreted language interface) Provides:.

If there is no standard naming for a package or other long term naming compatibility requirements involved with the rename, the Provides should be assumed to be deprecated and short lived and removed in the distro release after the next one (i.e., if introduced in FC-X, keep in all subsequent package revisions for distros FC-X and FC-(X+1), drop in FC-(X+2)), and the distro version where it is planned to be dropped documented in a comment in the specfile. Maintainers of affected packages should be notified and encouraged to switch to use the new name. Forward compatibility Provides: in older distro branches can be considered in order to make it possible for package maintainers to keep same simple specfiles between branches but still switch to the newer name.

For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there’s usually no need to add the Provides. Note however that the -devel subpackages of lib packages are pulled in as build dependencies using the package name, so adding the Provides is often appropriate there.

A procedure exists for indicating that a package is deprecated and may leave the distribution in the future. See Deprecating Packages.

If an application contains native and stable support for both IPv4 and IPv6, and support for IPv6 does not negatively affect IPv4 then both MUST be enabled in the Fedora package.

For details on how to package cron files, refer to: CronFiles.

If an update to your package resolves a known security concern (at the time of the update) with a Common Vulnerabilities and Exposures (CVE) number assigned to it, you should mention the CVE number in the RPM changelog entry.

Packages in the Fedora buildsystem are built in a mock chroot with no access to the internet. Packages must not depend or or use any network resources that they don’t themselves create (i.e., for tests). In no cases should source code be downloaded from any external sources, only from the lookaside cache and/or the Fedora git repository.

If your package introduces build time circular dependencies, you should use this macro to bootstrap your package:

If your package explicitly Provides: some functionality that is missing when bootstrapped, then that Provides: should look like:

Please note that usage of pre-built binaries in bootstrap still needs an exception from the Packaging Committee as stated in [General Exception Policy].

Applications which make use the SSL or TLS cryptographic protocols MUST follow Crypto Policies.

When packaging script files, where the interpreter to be used is specified in the first line of the script (the shebang line) following #!, the following rules apply:

Shebang lines for executable scripts are automatically modified to convert calls to env into direct use of the proper executable in /usr/bin. Various checks are also applied to verify that the shebang lines are valid, and the build process can fail as a result of these. Finally, other language-specific modifications may also be made. It is thus generally unnecessary to manually modify executable scripts to fix env usage as long as this functionality is enabled.

If the automatic checks and modifications break a package, there are two primary options:

If (and only if) the script needs to remain executable and cannot be modified to pass the checks, then the maintainer MAY elect to disable the checks and modifications. It is also possible to disable the functionality for specific paths or for specific shebang lines by setting %__brp_mangle_shebangs_exclude_from and %__brp_mangle_shebangs_exclude, respectively, using the same syntax as the settings described in Packaging:AutoProvidesAndRequiresFiltering. It is also possible to disable the functionality entirely by adding %undefine __brp_mangle_shebangs near the beginning of the specfile.

BRP scripts are injected at the end of %install (via the %__os_install_post macro) and perform some automatic sanity checks of, or adjustments to, files installed in the build root.

All packages SHOULD always be subject to all the BRP scripts, but sometimes it is necessary for a package to opt-out of certain ones. It is possible to disable any BRP script simply by defining the corresponding variable to %{nil}. For example, to disable the brp-python-bytecompile script:

Any package that disables a BRP script this way MUST also note the reason in an accompanying comment. For a list of the BRP scripts run by default, invoke:

For a list of all BRP scripts, invoke:

For the most part, these guidelines and the application-specific guidelines below cover packaging for both Fedora and EPEL. However, there are necessarily some differences. When packaging for EPEL, please also consult the EPEL packaging guidelines for additional information.

Some applications, languages and build systems have specific guidelines written for them, located on their own pages: