Alternatives provide means for parallel installation of packages which provide the same functionality by maintaining sets of symlinks (one per package) pointing to alternativized files like this:

  `+/path/original-file -> /etc/alternatives/packagename-original-file -> /path/original-file.suffix+`

  If a package contains a GUI application, then it SHOULD also install a `+.appdata.xml+` file into `+%{_metainfodir}+`. Installed `+.appdata.xml+` files MUST follow the http://people.freedesktop.org/~hughsient/appdata/[AppData specification page].

  == What is a Service?

  Sometimes a package is intended to be link:How_to_remove_a_package_at_end_of_life[removed from Fedora], but it is kept in Fedora for some additional (often indeterminate) time for various reasons including maintaining backwards compatibility. In order to prevent new packages from depending on such a package, it can be marked as *deprecated*.

  This document describes the conventions and customs surrounding the proper packaging of http://gap-system.org/[GAP] add-on packages in Fedora. Throughout this document, we use the word _add-on_ to substitute for GAP upstream's use of the word _package_, to avoid confusion with RPM packages.

  = Java Packaging Guidelines

  This page represents Fedora guidelines for packaging libraries and applications written in Java and related languages using Java Virtual Machine as bytecode interpreter. It does not aim to extensively describe packaging techniques and tips. RPM macros and commands used here are documented in man pages. Furthermore a separate https://fedora-java.github.io/howto/latest/[Java Packaging HOWTO] describes Java packaging techniques in detail and includes examples, templates and documentation aimed at packagers and Java developers who are taking their first steps in Java RPM packaging.

  This document provides best practices for the usage of http://mesonbuild.com/[the Meson build system] in Fedora packages. Meson is a build system (similar to automake) which can generate code for other lower-level build systems. For example, it can generate code for https://ninja-build.org/[ninja]. When packaging software which builds using Meson it's important to use the `+%meson+` macros instead of `+%ninja+` or other lower-level build system macros directly. The backend used by Meson could change.

  = Mono Packaging Guidelines

  == File Locations and Architectures

  == Versioning guidelines have moved

  = PHP Packaging Guidelines

  Fedora Packaging Guidelines for PHP addon modules

  In the Fedora.next world, we 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. The goal of this document is to set out the guidelines for creating per-Product configuration defaults.

  = Perl Packaging Guidelines

  == License tag

  = Python Packaging Guidelines

  == Python Version Support

  Python packages provide extra metadata about the package in the form of egg metadata. This document explains how to package those metadata.

  = R Packaging Guidelines

  == What is R?

  = Ruby Packaging Guidelines

  There are three basic categories of ruby packages: link:#RubyGems[ ruby gems], link:#Non-Gem_Packages[ non-gem ruby packages], and link:#ruby_applications[ applications written in ruby]. These guidelines contain sections common to all of these as well as sections which apply to each one individually. Be sure to read all the guidelines relevant to the type of ruby package you are building.

  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. This page offers a quick overview of RPM scriptlets and a number of common recipes for scriptlets in packages. For a more complete treatment of scriptlets, please see the http://www.rpm.org/max-rpm-snapshot/[Maximum RPM book].

  In Fedora, the package versioning scheme (which encompasses both the `+Version:+` and `+Release:+` tags, as well as `+Epoch:+`) balances two separate goals:

  Not everything can be packaged in Fedora. Most things considered to be "free software" or "open source software" are permitted, but definitions of these are not always consistent and Fedora has a few specific requirements and exceptions. This is an overview of some specific requirements and exceptions, but it is not intended to be exhaustive. If questions arise, the link:Packaging_Committee[Packaging Committee] and the Legal:Main[Legal Team] are the primary places to receive answers.