From 902a3c65037ad8c84dc2de121dc659b8b3b867f7 Mon Sep 17 00:00:00 2001
From: Maxwell G <maxwell@gtmx.me>
Date: Apr 21 2026 19:39:17 +0000
Subject: Migrate to Fedora Forge


---

diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index b9b1e82..0000000
--- a/.gitignore
+++ /dev/null
@@ -1,4 +0,0 @@
-/build/
-/cache/
-/public/
-/guidelines/**/*.html
diff --git a/Makefile b/Makefile
deleted file mode 100644
index 52c9fae..0000000
--- a/Makefile
+++ /dev/null
@@ -1,28 +0,0 @@
-mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
-mkfile_dir := $(patsubst %/,%,$(dir $(mkfile_path)))
-docsbuilder := $(abspath $(mkfile_dir)/docsbuilder.sh)
-
-doc:
-	$(docsbuilder) -b
-
-build:	doc
-
-.ONESHELL:
-serve: 
-	$(info *** Make sure to refresh pages without cache ***)
-	$(docsbuilder) -p
-
-watch:
-	$(docsbuilder) -a
-
-linkcheck:
-	$(docsbuilder) -k
-	$(docsbuilder) -p
-	linkchecker http://localhost:8080 --check-extern --no-robots \
-		--ignore-url "drupal.org" \
-		--ignore-url "file:///antora" \
-		--ignore-url 'http://localhost:8080/en-US'
-	$(docsbuilder) -k
-
-.DEFAULT_GOAL := doc
-.PHONY: doc linkcheck serve watch
diff --git a/README.md b/README.md
index 591ce37..03e8eae 100644
--- a/README.md
+++ b/README.md
@@ -1,96 +1,3 @@
-# Fedora Packaging Committee
+# Migrated to Fedora Forge
 
-Welcome!  This is the Pagure instance for the Fedora Packaging Committee.
-
-The Pagure repository is used to store the source of Packaging Guidelines,
-track related issues
-and accept changes via pull requests.
-
-For more information on the committee and its processes,
-see the page in the main Fedora wiki
-[here](https://fedoraproject.org/wiki/Packaging_Committee).
-
-You can view the actual packaging guidelines
-[here](https://docs.fedoraproject.org/en-US/packaging-guidelines/).
-
-## Packaging Guideline Development
-
-### Checking the Effect of Your Changes
-
-To quickly check whether the changes you have made to a .adoc file
-cause the desired changes to the HTML code,
-use Asciidoctor.
-It is in the package rubygem-asciidoctor,
-and is, despite the package name, usable from a command prompt:
-
-```
-$ asciidoctor path/to/file.adoc
-```
-
-This will generate an HTML file corresponding to the input file.
-The style will differ
-but the HTML code as such is supposed to match what will end up on the website,
-allowing you to see whether the Asciidoc code works as you intended.
-
-### Quick Preview in the Browser
-
-You can install the Asciidoctor browser extension
-from https://github.com/asciidoctor/asciidoctor-browser-extension
-to get a quick browser preview.
-As with running asciidoctor directly,
-the results won't look exactly
-like the final result will,
-but it's reasonable for checking the formatting.
-
-This will also work to preview files from within Pagure,
-which is handy for checking the results of pull requests
-without pulling and locally generating the documents.
-Simply navigate to a file and click the `Raw` button.
-
-Note that under Firefox,
-the extension will not run on `file://` URLs
-unless you press enter on the URL bar.
-
-### Building the Whole Set of Guidelines
-
-For building the whole set of guidelines locally
-and viewing them in the same style as on the website,
-there is a container-based build procedure.
-This will download and execute container blobs containing Antora,
-and produce a complete set of HTML documents and stylesheets,
-which can then be browsed through a temporary HTTP server.
-
-Prerequisites:
-
-* `make`
-* `podman`
-* `python3`
-
-Run the following commands and open http://localhost:8000/
-
-```
-$ make
-$ make serve
-```
-
-### Writing
-
-[Antora](https://antora.org/) is used for
-managing the various documents which comprise the guidelines
-and integrating them into the rest of Fedora Documentation.
-
-The guidelines themselves are written in
-[AsciiDoc](https://asciidoc.org).
-Some useful information about AsciiDoc can be found below:
-
-* [AsciiDoc Syntax Quick Reference](https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/)
-* [AsciiDoc Writer's Guide](https://asciidoctor.org/docs/asciidoc-writers-guide/)
-
-### Conventions and Preferences
-
-The Packaging Committee tries to follow the following,
-and it is preferred that pull requests do the same.
-
-* Use [Semantic Line Breaks](https://sembr.org/) to make diffing simpler.
-* Prefer `https://example.com[here]` over `link:https://example.com[here]`
-* Prefer `[#some-ref]` over `[[some-ref]]`
+https://forge.fedoraproject.org/packaging/guidelines
diff --git a/docsbuilder.sh b/docsbuilder.sh
deleted file mode 100755
index fcb54d6..0000000
--- a/docsbuilder.sh
+++ /dev/null
@@ -1,292 +0,0 @@
-#!/bin/bash
-# script to watch source directory for changes, and re-run build and preview
-#
-# License: MIT
-# https://fedoraproject.org/wiki/Licensing:MIT#Another_Minimal_variant_(found_in_libatomic_ops)
-#
-# Copyright (c) Fedora community contributors.
-#
-# THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED OR
-# IMPLIED. ANY USE IS AT YOUR OWN RISK.
-#
-# Permission is hereby granted to use or copy this program for any purpose,
-# provided the above notices are retained on all copies.  Permission to modify
-# the code and to distribute modified code is granted, provided the above
-# notices are retained, and a notice that the code was modified is included
-# with the above copyright notice.
-
-
-script_name="docsbuilder.sh"
-script_source="https://gitlab.com/fedora/docs/templates/fedora-docs-template/-/raw/main/${script_name}"
-version="1.2.0"
-image="docker.io/antora/antora"
-cmd="--html-url-extension-style=indexify site.yml"
-srcdir="guidelines"
-buildir="public"
-previewpidfile="preview.pid"
-
-# 4913: for vim users, vim creates a temporary file to test it can write to
-# directory
-# https://groups.google.com/g/vim_dev/c/sppdpElxY44
-# .git: so we don't get rebuilds each time git metadata changes
-inotifyignore="\.git.*|4913"
-
-watch_and_build () {
-    if ! command -v inotifywait > /dev/null
-    then
-        echo "inotifywait command could not be found. Please install inotify-tools."
-        echo "On Fedora, run: sudo dnf install inotify-tools"
-        stop_preview_and_exit
-    else
-        # check for git
-        # required to get ignorelist
-        if ! command -v git > /dev/null
-        then
-            echo "git command could not be found. Please install git."
-            echo "On Fedora, run: sudo dnf install git-core"
-            stop_preview_and_exit
-        else
-            # Get files not being tracked, we don't watch for changes in these.
-            # Could hard code, but people use different editors that may create
-            # temporary files that are updated regularly and so on, so better
-            # to get the list from git. It'll also look at global gitingore
-            # settings and so on.
-            inotifyignore="$(git status -s --ignored | grep '^!!' | sed -e 's/^!! //' | tr '\n' '|')${inotifyignore}"
-        fi
-
-        while true
-        do
-            echo "Watching current directory (excluding: ${inotifyignore}) for changes and re-building as required. Use Ctrl C to stop."
-            inotifywait -q --exclude "($inotifyignore)" -e modify,create,delete,move -r . && echo "Change detected, rebuilding.." && build
-        done
-    fi
-}
-
-build () {
-    if [ "$(uname)" == "Darwin" ]; then
-        # Running on macOS.
-        # Let's assume that the user has the Docker CE installed
-        # which doesn't require a root password.
-        echo ""
-        echo "This build script is using Docker container runtime to run the build in an isolated environment."
-        echo ""
-        docker run --rm -it -v $(pwd):/antora $image $cmd
-
-    elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then
-        # Running on Linux.
-        # Check whether podman is available, else faill back to docker
-        # which requires root.
-
-        if [ -n "$(command -v podman)" ]; then
-            echo ""
-            echo "This build script is using Podman to run the build in an isolated environment."
-            echo ""
-            podman run --rm -it -v $(pwd):/antora:z $image $cmd --stacktrace
-
-        elif [ -n "$(command -v docker)" ]; then
-            echo ""
-            echo "This build script is using Docker to run the build in an isolated environment."
-            echo ""
-
-            if groups | grep -wq "docker"; then
-                docker run --rm -it -v $(pwd):/antora:z $image $cmd
-            else
-                    echo ""
-                    echo "This build script is using $runtime to run the build in an isolated environment. You might be asked for your password."
-                    echo "You can avoid this by adding your user to the 'docker' group, but be aware of the security implications. See https://docs.docker.com/install/linux/linux-postinstall/."
-                    echo ""
-                    sudo docker run --rm -it -v $(pwd):/antora:z $image $cmd
-            fi
-
-        else
-            echo ""
-        echo "Error: Container runtime haven't been found on your system. Fix it by:"
-        echo "$ sudo dnf install podman"
-        exit 1
-        fi
-    fi
-}
-
-start_preview () {
-
-    # clean up a preview that may be running
-    stop_preview
-
-    # always run an initial build so preview shows latest version
-    build
-
-    if [ "$(uname)" == "Darwin" ]; then
-        # Running on macOS.
-        # Let's assume that the user has the Docker CE installed
-        # which doesn't require a root password.
-        echo "The preview will be available at http://localhost:8080/"
-        docker run --rm -v $(pwd):/antora:ro -v $(pwd)/nginx.conf:/etc/nginx/conf.d/default.conf:ro -p 8080:80 nginx
-
-    elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then
-        # Running on Linux.
-        # Fedora Workstation has python3 installed as a default, so using that
-        echo ""
-        echo "The preview is available at http://localhost:8080"
-        echo ""
-        pushd "${buildir}"  > /dev/null 2>&1
-            python3 -m http.server 8080 &
-            echo "$!" > ../"${previewpidfile}"
-        popd > /dev/null 2>&1
-    fi
-}
-
-stop_preview () {
-    if [ -e "${previewpidfile}" ]
-    then
-        PID=$(cat "${previewpidfile}")
-        kill $PID
-        echo "Stopping preview server (running with PID ${PID}).."
-        rm -f "${previewpidfile}"
-    else
-        echo "No running preview server found to stop: no ${previewpidfile} file found."
-    fi
-}
-
-stop_preview_and_exit ()
-{
-    # stop and also exit the script
-
-    # if stop_preview is trapped, then SIGINT doesn't stop the build loop. So
-    # we need to make sure we also exit the script.
-
-    # stop_preview is called before other functions, so we cannot add exit to
-    # it.
-    stop_preview
-    exit 0
-}
-
-
-# https://apple.stackexchange.com/questions/83939/compare-multi-digit-version-numbers-in-bash/123408#123408
-version () { echo "$@" | awk -F. '{ printf("%d%03d%03d%03d\n", $1,$2,$3,$4);  }';  }
-
-
-check_update () {
-    if ! command -v curl > /dev/null
-    then
-        echo "curl command could not be found. Please install curl."
-        echo "On Fedora, run: sudo dnf install curl"
-        exit 0
-    fi
-    script_version="$(grep "^version=" ${script_name} | cut -d '=' -f2 | tr --delete '"')"
-    tempdir="$(mktemp -d)"
-    echo "$tempdir"
-    pushd "$tempdir" > /dev/null 2>&1
-        curl "$script_source" --silent --output "${script_name}"
-        upstream_version="$(grep "^version=" ${script_name} | cut -d '=' -f2 | tr --delete '"')"
-        echo "${upstream_version}"
-        if [ $(version $upstream_version) -gt $(version $script_version)  ]; then
-            echo "Update available"
-            echo "Script version $upstream_version is available at $script_source"
-            echo "This version is $script_version."
-            echo "Please use the '-U' option to update."
-            echo
-        fi
-    popd > /dev/null 2&>1
-}
-
-install_update () {
-    if ! command -v curl > /dev/null
-    then
-        echo "curl command could not be found. Please install curl."
-        echo "On Fedora, run: sudo dnf install curl"
-        exit 0
-    fi
-    curl "$script_source" --silent --output "${script_name}.new"
-    mv "${script_name}.new" "${script_name}"
-    chmod +x "${script_name}"
-}
-
-usage() {
-    echo "$0: Build and preview Fedora antora based documentation"
-    echo
-    echo "Usage: $0 [-awbpkh]"
-    echo
-    echo "-a: start preview, start watcher and rebuilder"
-    echo "-w: start watcher and rebuilder"
-    echo "-b: rebuild"
-    echo "-p: start_preview"
-    echo "-k: stop_preview"
-    echo "-h: print this usage text and exit"
-    echo "-u: check builder script update"
-    echo "-U: install builder script from upstream"
-    echo
-    echo "Maintained by the Fedora documentation team."
-    echo "Please contact on our channels: https://docs.fedoraproject.org/en-US/fedora-docs/#find-docs"
-}
-
-# check if the script is being run in a Fedora docs repository
-if [ ! -e "site.yml" ]
-then
-    echo "site.yml not be found."
-    echo "This does not appear to be a Fedora Antora based documentation repository."
-    echo "Exiting."
-    echo
-    usage
-    exit 1
-fi
-
-
-if [ $# -lt 1 ]
-then
-    echo "No options provided, running preview with watch and build."
-    echo "Run script with '-h' to see all available options."
-    echo
-    echo
-    trap stop_preview_and_exit INT
-    start_preview
-    watch_and_build
-    stop_preview
-fi
-
-# parse options
-while getopts "awbpkhuU" OPTION
-do
-    case $OPTION in
-        a)
-            # handle sig INT to stop the preview
-            trap stop_preview_and_exit INT
-            start_preview
-            watch_and_build
-            stop_preview
-            exit 0
-            ;;
-        w)
-            watch_and_build
-            exit 0
-            ;;
-        b)
-            build
-            exit 0
-            ;;
-        p)
-            start_preview
-            echo "Please run ./${script_name} -k to stop the preview server"
-            exit 0
-            ;;
-        k)
-            stop_preview
-            exit 0
-            ;;
-        h)
-            usage
-            exit 0
-            ;;
-        u)
-            check_update
-            exit 0
-            ;;
-        U)
-            install_update
-            exit 0
-            ;;
-        ?)
-            usage
-            exit 1
-            ;;
-    esac
-done
diff --git a/guidelines/antora.yml b/guidelines/antora.yml
deleted file mode 100644
index 76b864a..0000000
--- a/guidelines/antora.yml
+++ /dev/null
@@ -1,16 +0,0 @@
-# Name will be mostly visible in the URL. Treat it as an indentifier.
-# Tip: If you want to use the local preview scripts that come with this repository, please change this value in the site.yml file as well. (under site/start_page)
-name: packaging-guidelines
-
-# Title will be visible on the page.
-title: Packaging Guidelines
-
-# If you don't plan to have multiple versions of the docs (for example, to document multiple versions of some software), you can ignore this field. Otherwise, change "master" to a specific version.
-version: master
-
-# We encourage you to name the index page as "index.adoc". If you absolutely have to use a different name, please reflect it here. You can ignore this field otherwise.
-start_page: ROOT:index.adoc
-
-# This lists all the menu definitions of your component.
-nav:
-- modules/ROOT/nav.adoc
diff --git a/guidelines/modules/ROOT/examples/addon.metainfo.xml b/guidelines/modules/ROOT/examples/addon.metainfo.xml
deleted file mode 100644
index 19d5d09..0000000
--- a/guidelines/modules/ROOT/examples/addon.metainfo.xml
+++ /dev/null
@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<component type="addon">
-  <id>gedit-bookmarks</id>
-  <extends>gedit.desktop</extends>
-  <name>Bookmarks</name>
-  <summary>Easy document navigation with bookmarks</summary>
-  <url type="homepage">https://wiki.gnome.org/Apps/Gedit/ShippedPlugins</url>
-  <url type="bugtracker">https://bugzilla.gnome.org/enter_bug.cgi?product=gedit&amp;component=Plugins</url>
-  <metadata_license>CC0-1.0</metadata_license>
-  <project_license>GPL-2.0+</project_license>
-</component>
diff --git a/guidelines/modules/ROOT/examples/app.metainfo.xml b/guidelines/modules/ROOT/examples/app.metainfo.xml
deleted file mode 100644
index e285c08..0000000
--- a/guidelines/modules/ROOT/examples/app.metainfo.xml
+++ /dev/null
@@ -1,38 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 Richard Hughes <richard@hughsie.com> -->
-<component type="desktop">
-  <id>comical.desktop</id>
-  <metadata_license>CC0-1.0</metadata_license>
-  <project_license>GPL-2.0+ and GFDL-1.3</project_license>
-  <name>Comical</name>
-  <summary>A Comic Archive Reader</summary>
-  <summary xml:lang="fr">Un Comic Archive Lecteur</summary>
-  <description>
-    <p>
-      Comical is an easy to use and cross-platform CBR and CBZ reader which
-      prefetches and caches pages for speed.
-    </p>
-    <p xml:lang="fr">
-      Comical est une CBR et CBZ lecteur facile à utiliser et
-      multi-plateforme qui prélectures et caches pages pour la vitesse.
-    </p>
-    <p>
-      Resized images are crisp, and you can view pages one or two at a time.
-      Comical is open-source, so feel free to contribute new features!
-    </p>
-    <p xml:lang="fr">
-      Images redimensionnées sont nettes, et vous pouvez voir une ou deux pages à la fois.
-      Comical est open-source, alors n'hésitez pas à apporter de nouvelles fonctionnalités!
-    </p>
-  </description>
-  <screenshots>
-    <screenshot type="default">
-      <image>http://comical.sourceforge.net/images/comical-0.5-linux.jpg</image>
-    </screenshot>
-    <screenshot>
-      <image>http://comical.sourceforge.net/images/comical-0.6-win32.jpg</image>
-    </screenshot>
-  </screenshots>
-  <url type="homepage">http://comical.sourceforge.net/</url>
-  <update_contact>richard_at_hughsie.com</update_contact>
-</component>
diff --git a/guidelines/modules/ROOT/examples/fonts/after-fontconfig-fixes.txt b/guidelines/modules/ROOT/examples/fonts/after-fontconfig-fixes.txt
deleted file mode 100644
index 068b015..0000000
--- a/guidelines/modules/ROOT/examples/fonts/after-fontconfig-fixes.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-Accanthis ADF Std  Regular                          Accanthis ADF Std                              100       80       0    131400  /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Regular.otf
-Accanthis ADF Std  Italic                           Accanthis ADF Std Italic                       100       80       100  131400  /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Italic.otf
-Accanthis ADF Std  Bold                             Accanthis ADF Std Bold                         100       200      0    131400  /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Bold.otf
-Accanthis ADF Std  Bold Italic                      Accanthis ADF Std Bold Italic                  100       200      100  131400  /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-BoldItalic.otf
-Dai Banna SIL      Light                            Dai Banna SIL Light                            100       50       0    1       /usr/share/fonts/sil-dai-banna-fonts/DBSILLR.ttf
-Dai Banna SIL      Light Italic                     Dai Banna SIL Light Italic                     100       80       100  1       /usr/share/fonts/sil-dai-banna-fonts/DBSILLO.ttf
-Dai Banna SIL      Medium Italic                    Dai Banna SIL Medium Italic                    100       80       100  2       /usr/share/fonts/sil-dai-banna-fonts/DBSILBO.ttf
-Dai Banna SIL      Medium                           Dai Banna SIL Medium                           100       100      0    2       /usr/share/fonts/sil-dai-banna-fonts/DBSILBR.ttf
-Dai Banna SIL      Medium                           Dai Banna SIL Medium                           100       100      0    1       /usr/share/fonts/sil-dai-banna-fonts/DBSILLB.ttf
-Dai Banna SIL      Black Italic                     Dai Banna SIL Black Italic                     100       200      100  2       /usr/share/fonts/sil-dai-banna-fonts/DBSILBC.ttf
-Dai Banna SIL      Medium Italic                    Dai Banna SIL Medium Italic                    100       200      100  1       /usr/share/fonts/sil-dai-banna-fonts/DBSILLC.ttf
-Dai Banna SIL      Black                            Dai Banna SIL Black                            100       210      0    2       /usr/share/fonts/sil-dai-banna-fonts/DBSILBB.ttf
-IBM Plex Sans                                       IBM Plex Sans                                  [85 100]  [0 200]  0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans                                       IBM Plex Sans                                  [85 100]  [0 200]  100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      SemiCondensed Thin               IBM Plex Sans SemiCondensed Thin               85        0        0    6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Thin.otf
-IBM Plex Sans      SemiCondensed Thin               IBM Plex Sans SemiCondensed Thin               85        0        0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      SemiCondensed Thin Italic        IBM Plex Sans SemiCondensed Thin Italic        85        0        100  6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-ThinItalic.otf
-IBM Plex Sans      SemiCondensed Thin Italic        IBM Plex Sans SemiCondensed Thin Italic        85        0        100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      SemiCondensed ExtraLight         IBM Plex Sans SemiCondensed ExtraLight         85        40       0    6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-ExtraLight.otf
-IBM Plex Sans      SemiCondensed ExtraLight         IBM Plex Sans SemiCondensed ExtraLight         85        40       0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      SemiCondensed ExtraLight Italic  IBM Plex Sans SemiCondensed ExtraLight Italic  85        40       100  6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-ExtraLightItalic.otf
-IBM Plex Sans      SemiCondensed ExtraLight Italic  IBM Plex Sans SemiCondensed ExtraLight Italic  85        40       100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      SemiCondensed Light              IBM Plex Sans SemiCondensed Light              85        50       0    6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Light.otf
-IBM Plex Sans      SemiCondensed Light              IBM Plex Sans SemiCondensed Light              85        50       0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      SemiCondensed Light Italic       IBM Plex Sans SemiCondensed Light Italic       85        50       100  6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-LightItalic.otf
-IBM Plex Sans      SemiCondensed Light Italic       IBM Plex Sans SemiCondensed Light Italic       85        50       100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      SemiCondensed                    IBM Plex Sans SemiCondensed                    85        80       0    6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Regular.otf
-IBM Plex Sans      SemiCondensed                    IBM Plex Sans SemiCondensed                    85        80       0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      SemiCondensed Italic             IBM Plex Sans SemiCondensed Italic             85        80       100  6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Italic.otf
-IBM Plex Sans      SemiCondensed Italic             IBM Plex Sans SemiCondensed Italic             85        80       100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      SemiCondensed Text               IBM Plex Sans SemiCondensed Text               85        90       0    6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Text.otf
-IBM Plex Sans      SemiCondensed Text               IBM Plex Sans SemiCondensed Text               85        90       0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      SemiCondensed Text Italic        IBM Plex Sans SemiCondensed Text Italic        85        90       100  6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-TextItalic.otf
-IBM Plex Sans      SemiCondensed Text Italic        IBM Plex Sans SemiCondensed Text Italic        85        90       100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      SemiCondensed Medium             IBM Plex Sans SemiCondensed Medium             85        100      0    6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Medium.otf
-IBM Plex Sans      SemiCondensed Medium             IBM Plex Sans SemiCondensed Medium             85        100      0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      SemiCondensed Medium Italic      IBM Plex Sans SemiCondensed Medium Italic      85        100      100  6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-MediumItalic.otf
-IBM Plex Sans      SemiCondensed Medium Italic      IBM Plex Sans SemiCondensed Medium Italic      85        100      100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      SemiCondensed SemiBold           IBM Plex Sans SemiCondensed SemiBold           85        180      0    6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-SemiBold.otf
-IBM Plex Sans      SemiCondensed SemiBold           IBM Plex Sans SemiCondensed SemiBold           85        180      0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      SemiCondensed SemiBold Italic    IBM Plex Sans SemiCondensed SemiBold Italic    85        180      100  6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-SemiBoldItalic.otf
-IBM Plex Sans      SemiCondensed SemiBold Italic    IBM Plex Sans SemiCondensed SemiBold Italic    85        180      100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      SemiCondensed Bold               IBM Plex Sans SemiCondensed Bold               85        200      0    6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Bold.otf
-IBM Plex Sans      SemiCondensed Bold               IBM Plex Sans SemiCondensed Bold               85        200      0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      SemiCondensed Bold Italic        IBM Plex Sans SemiCondensed Bold Italic        85        200      100  6       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-BoldItalic.otf
-IBM Plex Sans      SemiCondensed Bold Italic        IBM Plex Sans SemiCondensed Bold Italic        85        200      100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      Thin                             IBM Plex Sans Thin                             100       0        0    7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Thin.otf
-IBM Plex Sans      Thin                             IBM Plex Sans Thin                             100       0        0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      Thin                             IBM Plex Sans Thin                             100       0        0    4       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Thin.otf
-IBM Plex Sans      Thin                             IBM Plex Sans Thin                             100       0        0    3       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Thin.otf
-IBM Plex Sans      Thin                             IBM Plex Sans Thin                             100       0        0    2       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Thin.otf
-IBM Plex Sans      Thin                             IBM Plex Sans Thin                             100       0        0    1       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Thin.otf
-IBM Plex Sans      Thin Italic                      IBM Plex Sans Thin Italic                      100       0        100  7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-ThinItalic.otf
-IBM Plex Sans      Thin Italic                      IBM Plex Sans Thin Italic                      100       0        100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      ExtraLight                       IBM Plex Sans ExtraLight                       100       40       0    7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-ExtraLight.otf
-IBM Plex Sans      ExtraLight                       IBM Plex Sans ExtraLight                       100       40       0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      ExtraLight                       IBM Plex Sans ExtraLight                       100       40       0    4       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-ExtraLight.otf
-IBM Plex Sans      ExtraLight                       IBM Plex Sans ExtraLight                       100       40       0    3       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-ExtraLight.otf
-IBM Plex Sans      ExtraLight                       IBM Plex Sans ExtraLight                       100       40       0    2       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-ExtraLight.otf
-IBM Plex Sans      ExtraLight                       IBM Plex Sans ExtraLight                       100       40       0    1       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-ExtraLight.otf
-IBM Plex Sans      ExtraLight Italic                IBM Plex Sans ExtraLight Italic                100       40       100  7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-ExtraLightItalic.otf
-IBM Plex Sans      ExtraLight Italic                IBM Plex Sans ExtraLight Italic                100       40       100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      Light                            IBM Plex Sans Light                            100       50       0    7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Light.otf
-IBM Plex Sans      Light                            IBM Plex Sans Light                            100       50       0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      Light                            IBM Plex Sans Light                            100       50       0    4       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Light.otf
-IBM Plex Sans      Light                            IBM Plex Sans Light                            100       50       0    3       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Light.otf
-IBM Plex Sans      Light                            IBM Plex Sans Light                            100       50       0    2       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Light.otf
-IBM Plex Sans      Light                            IBM Plex Sans Light                            100       50       0    1       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Light.otf
-IBM Plex Sans      Light Italic                     IBM Plex Sans Light Italic                     100       50       100  7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-LightItalic.otf
-IBM Plex Sans      Light Italic                     IBM Plex Sans Light Italic                     100       50       100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      Regular                          IBM Plex Sans                                  100       80       0    7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Regular.otf
-IBM Plex Sans      Regular                          IBM Plex Sans                                  100       80       0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      Regular                          IBM Plex Sans                                  100       80       0    4       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Regular.otf
-IBM Plex Sans      Regular                          IBM Plex Sans                                  100       80       0    3       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Regular.otf
-IBM Plex Sans      Regular                          IBM Plex Sans                                  100       80       0    2       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Regular.otf
-IBM Plex Sans      Regular                          IBM Plex Sans                                  100       80       0    1       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Regular.otf
-IBM Plex Sans      Italic                           IBM Plex Sans Italic                           100       80       100  7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Italic.otf
-IBM Plex Sans      Italic                           IBM Plex Sans Italic                           100       80       100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      Text                             IBM Plex Sans Text                             100       90       0    7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Text.otf
-IBM Plex Sans      Text                             IBM Plex Sans Text                             100       90       0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      Text                             IBM Plex Sans Text                             100       90       0    4       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Text.otf
-IBM Plex Sans      Text                             IBM Plex Sans Text                             100       90       0    3       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Text.otf
-IBM Plex Sans      Text                             IBM Plex Sans Text                             100       90       0    2       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Text.otf
-IBM Plex Sans      Text                             IBM Plex Sans Text                             100       90       0    1       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Text.otf
-IBM Plex Sans      Text Italic                      IBM Plex Sans Text Italic                      100       90       100  7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-TextItalic.otf
-IBM Plex Sans      Text Italic                      IBM Plex Sans Text Italic                      100       90       100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      Medium                           IBM Plex Sans Medium                           100       100      0    7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Medium.otf
-IBM Plex Sans      Medium                           IBM Plex Sans Medium                           100       100      0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      Medium                           IBM Plex Sans Medium                           100       100      0    4       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Medium.otf
-IBM Plex Sans      Medium                           IBM Plex Sans Medium                           100       100      0    3       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Medium.otf
-IBM Plex Sans      Medium                           IBM Plex Sans Medium                           100       100      0    2       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Medium.otf
-IBM Plex Sans      Medium                           IBM Plex Sans Medium                           100       100      0    1       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Medium.otf
-IBM Plex Sans      Medium Italic                    IBM Plex Sans Medium Italic                    100       100      100  7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-MediumItalic.otf
-IBM Plex Sans      Medium Italic                    IBM Plex Sans Medium Italic                    100       100      100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      SemiBold                         IBM Plex Sans SemiBold                         100       180      0    7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-SemiBold.otf
-IBM Plex Sans      SemiBold                         IBM Plex Sans SemiBold                         100       180      0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      SemiBold                         IBM Plex Sans SemiBold                         100       180      0    4       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-SemiBold.otf
-IBM Plex Sans      SemiBold                         IBM Plex Sans SemiBold                         100       180      0    3       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-SemiBold.otf
-IBM Plex Sans      SemiBold                         IBM Plex Sans SemiBold                         100       180      0    2       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-SemiBold.otf
-IBM Plex Sans      SemiBold                         IBM Plex Sans SemiBold                         100       180      0    1       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-SemiBold.otf
-IBM Plex Sans      SemiBold Italic                  IBM Plex Sans SemiBold Italic                  100       180      100  7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-SemiBoldItalic.otf
-IBM Plex Sans      SemiBold Italic                  IBM Plex Sans SemiBold Italic                  100       180      100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans      Bold                             IBM Plex Sans Bold                             100       200      0    7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Bold.otf
-IBM Plex Sans      Bold                             IBM Plex Sans Bold                             100       200      0    5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans      Bold                             IBM Plex Sans Bold                             100       200      0    4       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Bold.otf
-IBM Plex Sans      Bold                             IBM Plex Sans Bold                             100       200      0    3       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Bold.otf
-IBM Plex Sans      Bold                             IBM Plex Sans Bold                             100       200      0    2       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Bold.otf
-IBM Plex Sans      Bold                             IBM Plex Sans Bold                             100       200      0    1       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Bold.otf
-IBM Plex Sans      Bold Italic                      IBM Plex Sans Bold Italic                      100       200      100  7       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-BoldItalic.otf
-IBM Plex Sans      Bold Italic                      IBM Plex Sans Bold Italic                      100       200      100  5       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
diff --git a/guidelines/modules/ROOT/examples/fonts/before-fontconfig-fixes.txt b/guidelines/modules/ROOT/examples/fonts/before-fontconfig-fixes.txt
deleted file mode 100644
index b1579c3..0000000
--- a/guidelines/modules/ROOT/examples/fonts/before-fontconfig-fixes.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-Accanthis ADF Std         Regular                      AccanthisADFStd-Regular                        100       80       0    131400  /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Regular.otf
-Accanthis ADF Std         Italic                       AccanthisADFStd-Italic                         100       80       100  131400  /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Italic.otf
-Accanthis ADF Std         Bold                         AccanthisADFStd-Bold                           100       200      0    131400  /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Bold.otf
-Accanthis ADF Std         Bold Italic                  AccanthisADFStd-BoldItalic                     100       200      100  131400  /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-BoldItalic.otf
-Dai Banna SIL Book        Regular                      Dai Banna SIL Book                             100       80       0    144179  /usr/share/fonts/sil-dai-banna-fonts/DBSILBR.ttf
-Dai Banna SIL Book        Italic                       Dai Banna SIL Book Italic                      100       80       100  144179  /usr/share/fonts/sil-dai-banna-fonts/DBSILBO.ttf
-Dai Banna SIL Book        Bold                         Dai Banna SIL Book Bold                        100       200      0    144179  /usr/share/fonts/sil-dai-banna-fonts/DBSILBB.ttf
-Dai Banna SIL Book        Bold Italic                  Dai Banna SIL Book Bold Italic                 100       200      100  144179  /usr/share/fonts/sil-dai-banna-fonts/DBSILBC.ttf
-Dai Banna SIL Light       Regular                      Dai Banna SIL Light                            100       80       0    144179  /usr/share/fonts/sil-dai-banna-fonts/DBSILLR.ttf
-Dai Banna SIL Light       Italic                       Dai Banna SIL Light Italic                     100       80       100  144179  /usr/share/fonts/sil-dai-banna-fonts/DBSILLO.ttf
-Dai Banna SIL Light       Bold                         Dai Banna SIL Light Bold                       100       200      0    144179  /usr/share/fonts/sil-dai-banna-fonts/DBSILLB.ttf
-Dai Banna SIL Light       Bold Italic                  Dai Banna SIL Light Bold Italic                100       200      100  144179  /usr/share/fonts/sil-dai-banna-fonts/DBSILLC.ttf
-IBM Plex Sans             Thin                         IBM Plex Sans Thin                             100       0        0    196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Thin.otf
-IBM Plex Sans             Thin Italic                  IBM Plex Sans Thin Italic                      100       0        100  196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-ThinItalic.otf
-IBM Plex Sans             ExtraLight                   IBM Plex Sans ExtraLight                       100       40       0    196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-ExtraLight.otf
-IBM Plex Sans             ExtraLight Italic            IBM Plex Sans ExtraLight Italic                100       40       100  196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-ExtraLightItalic.otf
-IBM Plex Sans             Light                        IBM Plex Sans Light                            100       50       0    196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Light.otf
-IBM Plex Sans             Light Italic                 IBM Plex Sans Light Italic                     100       50       100  196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-LightItalic.otf
-IBM Plex Sans             Regular                      IBM Plex Sans                                  100       80       0    196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Regular.otf
-IBM Plex Sans             Italic                       IBM Plex Sans Italic                           100       80       100  196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Italic.otf
-IBM Plex Sans             Text                         IBM Plex Sans Text                             100       90       0    196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Text.otf
-IBM Plex Sans             Text Italic                  IBM Plex Sans Text Italic                      100       90       100  196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-TextItalic.otf
-IBM Plex Sans             Medium                       IBM Plex Sans Medium                           100       100      0    196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Medium.otf
-IBM Plex Sans             Medium Italic                IBM Plex Sans Medium Italic                    100       100      100  196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-MediumItalic.otf
-IBM Plex Sans             SemiBold                     IBM Plex Sans SemiBold                         100       180      0    196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-SemiBold.otf
-IBM Plex Sans             SemiBold Italic              IBM Plex Sans SemiBold Italic                  100       180      100  196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-SemiBoldItalic.otf
-IBM Plex Sans             Bold                         IBM Plex Sans Bold                             100       200      0    196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Bold.otf
-IBM Plex Sans             Bold Italic                  IBM Plex Sans Bold Italic                      100       200      100  196673  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-BoldItalic.otf
-IBM Plex Sans Arabic      Thin                         IBM Plex Sans Arabic Thin                      100       0        0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Thin.otf
-IBM Plex Sans Arabic      ExtraLight                   IBM Plex Sans Arabic ExtraLight                100       40       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-ExtraLight.otf
-IBM Plex Sans Arabic      Light                        IBM Plex Sans Arabic Light                     100       50       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Light.otf
-IBM Plex Sans Arabic      Regular                      IBM Plex Sans Arabic                           100       80       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Regular.otf
-IBM Plex Sans Arabic      Text                         IBM Plex Sans Arabic Text                      100       90       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Text.otf
-IBM Plex Sans Arabic      Medium                       IBM Plex Sans Arabic Medium                    100       100      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Medium.otf
-IBM Plex Sans Arabic      SemiBold                     IBM Plex Sans Arabic SemiBold                  100       180      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-SemiBold.otf
-IBM Plex Sans Arabic      Bold                         IBM Plex Sans Arabic Bold                      100       200      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansArabic-Bold.otf
-IBM Plex Sans Condensed   Thin                         IBM Plex Sans Condensed Thin                   75        0        0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Thin.otf
-IBM Plex Sans Condensed   Thin Italic                  IBM Plex Sans Condensed Thin Italic            75        0        100  65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-ThinItalic.otf
-IBM Plex Sans Condensed   ExtraLight                   IBM Plex Sans Condensed ExtraLight             75        40       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-ExtraLight.otf
-IBM Plex Sans Condensed   ExtraLight Italic            IBM Plex Sans Condensed ExtraLight Italic      75        40       100  65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-ExtraLightItalic.otf
-IBM Plex Sans Condensed   Light                        IBM Plex Sans Condensed Light                  75        50       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Light.otf
-IBM Plex Sans Condensed   Light Italic                 IBM Plex Sans Condensed Light Italic           75        50       100  65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-LightItalic.otf
-IBM Plex Sans Condensed   Regular                      IBM Plex Sans Condensed                        75        80       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Regular.otf
-IBM Plex Sans Condensed   Italic                       IBM Plex Sans Condensed Italic                 75        80       100  65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Italic.otf
-IBM Plex Sans Condensed   Text                         IBM Plex Sans Condensed Text                   75        90       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Text.otf
-IBM Plex Sans Condensed   Text Italic                  IBM Plex Sans Condensed Text Italic            75        90       100  65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-TextItalic.otf
-IBM Plex Sans Condensed   Medium                       IBM Plex Sans Condensed Medium                 75        100      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Medium.otf
-IBM Plex Sans Condensed   Medium Italic                IBM Plex Sans Condensed Medium Italic          75        100      100  65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-MediumItalic.otf
-IBM Plex Sans Condensed   SemiBold                     IBM Plex Sans Condensed SemiBold               75        180      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-SemiBold.otf
-IBM Plex Sans Condensed   SemiBold Italic              IBM Plex Sans Condensed SemiBold Italic        75        180      100  65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-SemiBoldItalic.otf
-IBM Plex Sans Condensed   Bold                         IBM Plex Sans Condensed Bold                   75        200      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Bold.otf
-IBM Plex Sans Condensed   Bold Italic                  IBM Plex Sans Condensed Bold Italic            75        200      100  65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-BoldItalic.otf
-IBM Plex Sans Devanagari  Thin                         IBM Plex Sans Devanagari Thin                  100       0        0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Thin.otf
-IBM Plex Sans Devanagari  ExtraLight                   IBM Plex Sans Devanagari ExtraLight            100       40       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-ExtraLight.otf
-IBM Plex Sans Devanagari  Light                        IBM Plex Sans Devanagari Light                 100       50       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Light.otf
-IBM Plex Sans Devanagari  Regular                      IBM Plex Sans Devanagari                       100       80       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Regular.otf
-IBM Plex Sans Devanagari  Text                         IBM Plex Sans Devanagari Text                  100       90       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Text.otf
-IBM Plex Sans Devanagari  Medium                       IBM Plex Sans Devanagari Medium                100       100      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Medium.otf
-IBM Plex Sans Devanagari  SemiBold                     IBM Plex Sans Devanagari SemiBold              100       180      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-SemiBold.otf
-IBM Plex Sans Devanagari  Bold                         IBM Plex Sans Devanagari Bold                  100       200      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansDevanagari-Bold.otf
-IBM Plex Sans Hebrew      Thin                         IBM Plex Sans Hebrew Thin                      100       0        0    65667   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Thin.otf
-IBM Plex Sans Hebrew      ExtraLight                   IBM Plex Sans Hebrew ExtraLight                100       40       0    65667   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-ExtraLight.otf
-IBM Plex Sans Hebrew      Light                        IBM Plex Sans Hebrew Light                     100       50       0    65667   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Light.otf
-IBM Plex Sans Hebrew      Regular                      IBM Plex Sans Hebrew                           100       80       0    65667   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Regular.otf
-IBM Plex Sans Hebrew      Text                         IBM Plex Sans Hebrew Text                      100       90       0    65667   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Text.otf
-IBM Plex Sans Hebrew      Medium                       IBM Plex Sans Hebrew Medium                    100       100      0    65667   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Medium.otf
-IBM Plex Sans Hebrew      SemiBold                     IBM Plex Sans Hebrew SemiBold                  100       180      0    65667   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-SemiBold.otf
-IBM Plex Sans Hebrew      Bold                         IBM Plex Sans Hebrew Bold                      100       200      0    65667   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansHebrew-Bold.otf
-IBM Plex Sans Thai        Thin                         IBM Plex Sans Thai Thin                        100       0        0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Thin.otf
-IBM Plex Sans Thai        ExtraLight                   IBM Plex Sans Thai ExtraLight                  100       40       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-ExtraLight.otf
-IBM Plex Sans Thai        Light                        IBM Plex Sans Thai Light                       100       50       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Light.otf
-IBM Plex Sans Thai        Regular                      IBM Plex Sans Thai                             100       80       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Regular.otf
-IBM Plex Sans Thai        Text                         IBM Plex Sans Thai Text                        100       90       0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Text.otf
-IBM Plex Sans Thai        Medium                       IBM Plex Sans Thai Medium                      100       100      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Medium.otf
-IBM Plex Sans Thai        SemiBold                     IBM Plex Sans Thai SemiBold                    100       180      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-SemiBold.otf
-IBM Plex Sans Thai        Bold                         IBM Plex Sans Thai Bold                        100       200      0    65601   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansThai-Bold.otf
-IBM Plex Sans Var                                      IBM Plex Sans Var Regular                      [85 100]  [0 200]  0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var                                      IBM Plex Sans Var Italic                       [85 100]  [0 200]  100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Thin Condensed               IBM Plex Sans Var Thin Condensed               85        0        0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Thin Condensed Italic        IBM Plex Sans Var Thin Condensed Italic        85        0        100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         ExtraLight Condensed         IBM Plex Sans Var ExtraLight Condensed         85        40       0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         ExtraLight Condensed Italic  IBM Plex Sans Var ExtraLight Condensed Italic  85        40       100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Light Condensed              IBM Plex Sans Var Light Condensed              85        50       0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Light Condensed Italic       IBM Plex Sans Var Light Condensed Italic       85        50       100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Condensed                    IBM Plex Sans Var Condensed                    85        80       0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Condensed Italic             IBM Plex Sans Var Condensed Italic             85        80       100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Text Condensed               IBM Plex Sans Var Text Condensed               85        90       0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Text Condensed Italic        IBM Plex Sans Var Text Condensed Italic        85        90       100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Medium Condensed             IBM Plex Sans Var Medium Condensed             85        100      0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Medium Condensed Italic      IBM Plex Sans Var Medium Condensed Italic      85        100      100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         SemiBold Condensed           IBM Plex Sans Var SemiBold Condensed           85        180      0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         SemiBold Condensed Italic    IBM Plex Sans Var SemiBold Condensed Italic    85        180      100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Bold Condensed               IBM Plex Sans Var Bold Condensed               85        200      0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Bold Condensed Italic        IBM Plex Sans Var Bold Condensed Italic        85        200      100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Thin                         IBM Plex Sans Var Thin                         100       0        0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Thin Italic                  IBM Plex Sans Var Thin Italic                  100       0        100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         ExtraLight                   IBM Plex Sans Var ExtraLight                   100       40       0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         ExtraLight Italic            IBM Plex Sans Var ExtraLight Italic            100       40       100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Light                        IBM Plex Sans Var Light                        100       50       0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Light Italic                 IBM Plex Sans Var Light Italic                 100       50       100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Regular                      IBM Plex Sans Var Regular                      100       80       0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Italic                       IBM Plex Sans Var Italic                       100       80       100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Text                         IBM Plex Sans Var Text                         100       90       0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Text Italic                  IBM Plex Sans Var Text Italic                  100       90       100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Medium                       IBM Plex Sans Var Medium                       100       100      0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Medium Italic                IBM Plex Sans Var Medium Italic                100       100      100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         SemiBold                     IBM Plex Sans Var SemiBold                     100       180      0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         SemiBold Italic              IBM Plex Sans Var SemiBold Italic              100       180      100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
-IBM Plex Sans Var         Bold                         IBM Plex Sans Var Bold                         100       200      0    65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf
-IBM Plex Sans Var         Bold Italic                  IBM Plex Sans Var Bold Italic                  100       200      100  65536   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf
diff --git a/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-0-simple.spec b/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-0-simple.spec
deleted file mode 100644
index 9fed5b2..0000000
--- a/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-0-simple.spec
+++ /dev/null
@@ -1,91 +0,0 @@
-# Packaging template: basic single-family fonts packaging.
-#
-# SPDX-License-Identifier: MIT
-#
-# This template documents the minimal set of spec declarations, necessary to
-# package a single font family, from a single dedicated source archive.
-#
-# It is part of the following set of packaging templates:
-# “fonts-0-simple”: basic single-family fonts packaging
-# “fonts-1-full”:   less common patterns for single-family fonts packaging
-# “fonts-2-multi”:  multi-family fonts packaging
-# “fonts-3-sub”:    packaging fonts, released as part of something else
-#
-# A font family is composed of font files, that share a single design, and
-# differ ONLY in:
-# — Weight        Bold, Black…
-# – Width∕Stretch Narrow, Condensed, Expanded…
-# — Slope/Slant   Italic, Oblique
-# Optical sizing  Caption…
-#
-# Those parameters correspond to the default axes of OpenType variable fonts:
-# https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg#registered-axis-tags
-# The variable fonts model is an extension of the WWS model described in the
-# WPF Font Selection Model whitepaper (2007):
-# https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Components.PostAttachments/00/02/24/90/36/WPF%20Font%20Selection%20Model.pdf
-#
-# Do not rely on the naming upstream chose, to define family boundaries, it
-# will often be wrong.
-#
-# Declaration order is chosen to limit divergence between those templates, and
-# simplify cut and pasting.
-#
-Version: 
-Release: 
-URL:     
-
-# The identifier of the entity, that released the font family.
-%global foundry           
-# The font family license identifier. Adjust as necessary. The OFL is our
-# recommended font license.
-%global fontlicense       OFL
-#
-# The following directives are lists of space-separated shell globs
-#   – matching files associated with the font family,
-#   – as they exist in the build root,
-#   — at the end of the %build stage:
-# – legal files (licensing…)
-%global fontlicenses      OFL.txt
-# – documentation files
-%global fontdocs          *.txt
-# – exclusions from the ”fontdocs” list
-%global fontdocsex        %{fontlicenses}
-
-# The human-friendly font family name, whitespace included, restricted to the
-# the Basic Latin Unicode block.
-%global fontfamily        
-%global fontsummary       
-#
-# More shell glob lists:
-# – font family files
-%global fonts             *.otf
-# – fontconfig files
-%global fontconfs         %{SOURCE10}
-#
-# A multi-line description block for the generated package.
-%global fontdescription   %{expand:
-}
-
-Source0:  
-# Adjust as necessary. Keeping the filename in sync with the package name is a good idea.
-# See the fontconfig templates in fonts-rpm-templates for information on how to
-# write good fontconfig files and choose the correct priority [number].
-Source10: [number]-%{fontpkgname}.conf
-
-%fontpkg
-
-%prep
-%setup
-
-%build
-%fontbuild
-
-%install
-%fontinstall
-
-%check
-%fontcheck
-
-%fontfiles
-
-%changelog
diff --git a/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-1-full.spec b/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-1-full.spec
deleted file mode 100644
index 8c74b11..0000000
--- a/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-1-full.spec
+++ /dev/null
@@ -1,95 +0,0 @@
-# Packaging template: less common patterns for single-family fonts packaging.
-#
-# SPDX-License-Identifier: MIT
-#
-# This template documents less common spec declarations, used when packaging a
-# single font family, from a single dedicated source archive.
-#
-# It is part of the following set of packaging templates:
-# “fonts-0-simple”: basic single-family fonts packaging
-# “fonts-1-full”:   less common patterns for single-family fonts packaging
-# “fonts-2-multi”:  multi-family fonts packaging
-# “fonts-3-sub”:    packaging fonts, released as part of something else
-#
-Version: 
-Release: 
-URL:     
-
-%global foundry           
-%global fontlicense       OFL
-#
-# The following directives are lists of space-separated shell globs
-#   – matching files associated with the font family,
-#   – as they exist in the build root,
-#   — at the end of the %build stage:
-# – legal files (licensing…)
-%global fontlicenses      OFL.txt
-# – exclusions from the “fontlicenses” list
-%global fontlicensesex    
-# – documentation files
-%global fontdocs          
-# – exclusions from the “fontdocs” list
-%global fontdocsex        %{fontlicenses}
-
-%global fontfamily        
-%global fontsummary       
-# A container for additional subpackage declarations.
-%global fontpkgheader     %{expand:
-Obsoletes: 
-}
-#
-# More shell glob lists:
-# – font family files
-%global fonts             
-# – exclusions from the “fonts” list)
-%global fontsex           
-# – fontconfig files
-%global fontconfs         %{SOURCE10}
-# – exclusions from the “fontconfs” list
-%global fontconfsex       
-# – appstream files, if any (generated automatically otherwise)
-%global fontappstreams    
-# – exclusions from the “fontappstreams” list
-%global fontappstreamsex  
-#
-%global fontdescription   %{expand:
-}
-
-Source0:  
-Source10: [number]-%{fontpkgname}.conf
-
-%fontpkg
-
-# Font creators love to bundle bulky documentation files, that show off their
-# font (typically, as pdf specimens). Split those files in a dedicated optional
-# doc package.
-%package   doc
-Summary:   %{name} optional documentation files
-BuildArch: noarch
-%description doc
-This package provides optional documentation files shipped with %{name}.
-
-%prep
-%setup
-# Convert upstream files to UTF-8 and Unix end of lines if necessary
-# Optional arguments:
-# -e [encoding] source OS encoding (auto-detected otherwise)
-# -n            do not recode files, only adjust folding and end of lines
-%linuxtext *.txt
-
-%build
-%fontbuild
-
-%install
-%fontinstall
-
-%check
-%fontcheck
-
-%fontfiles
-
-%files doc
-%license OFL.txt
-%doc *.pdf
-
-%changelog
diff --git a/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-2-multi.spec b/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-2-multi.spec
deleted file mode 100644
index a56646b..0000000
--- a/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-2-multi.spec
+++ /dev/null
@@ -1,132 +0,0 @@
-# Packaging template: multi-family fonts packaging.
-#
-# SPDX-License-Identifier: MIT
-#
-# This template documents spec declarations, used when packaging multiple font
-# families, from a single dedicated source archive. The source rpm is named
-# after the first (main) font family). Look up “fonts-3-sub” when the source
-# rpm needs to be named some other way.
-#
-# It is part of the following set of packaging templates:
-# “fonts-0-simple”: basic single-family fonts packaging
-# “fonts-1-full”:   less common patterns for single-family fonts packaging
-# “fonts-2-multi”:  multi-family fonts packaging
-# “fonts-3-sub”:    packaging fonts, released as part of something else
-#
-Version: 
-Release: 
-URL:     
-
-# The following declarations will be aliased to [variable]0 and reused for all
-# generated *-fonts packages unless overriden by a specific [variable][number]
-# declaration.
-%global foundry           
-%global fontlicense       
-%global fontlicenses      
-%global fontlicensesex    
-%global fontdocs          
-%global fontdocsex        %{fontlicenses}
-
-# A text block that can be reused as part of the description of each generated
-# subpackage.
-%global common_description %{expand:
-}
-
-# Declaration for the subpackage containing the first font family. Also used as
-# source rpm info. All the [variable]0 declarations are equivalent and aliased
-# to [variable].
-
-%global fontfamily0       
-%global fontsummary0      
-%global fontpkgheader0    %{expand:
-}
-%global fonts0            
-%global fontsex0          
-%global fontconfs0        %{SOURCE10}
-%global fontconfsex0      
-%global fontappstreams0   
-%global fontappstreamsex0 
-%global fontdescription0  %{expand:
-%{common_description}
-Additional text…}
-
-# Declaration for the subpackage containing the second font family.
-%global fontfamily1       
-%global fontsummary1      
-%global fontpkgheader1    %{expand:
-}
-%global fonts1            
-%global fontsex1          
-%global fontconfs1        %{SOURCE11}
-%global fontconfsex1      
-%global fontappstreams1   
-%global fontappstreamsex1 
-%global fontdescription1  %{expand:
-%{common_description}
-Other Additional text…}
-#
-# Continue as necessary…
-
-Source0:  
-Source10: [number]-%{fontpkgname0}.conf
-Source11: [number]-%{fontpkgname1}.conf
-
-# “fontpkg” will generate the font subpackage headers corresponding to the
-# elements declared above.
-# “fontpkg” accepts the following selection arguments:
-# – “-a”          process everything
-# – “-z [number]” process a specific declaration block
-# If no flag is specified it will only process the zero/nosuffix block.
-%fontpkg -a
-
-# “fontmetapkg” will generate a font meta(sub)package header for all the font
-# subpackages generated in this spec. Optional arguments:
-# – “-n [name]”      use [name] as metapackage name
-# – “-s [variable]”  use the content of [variable] as metapackage summary
-# – “-d [variable]”  use the content of [variable] as metapackage description
-# – “-z [numbers]”   restrict metapackaging to [numbers] comma-separated list
-#                    of font package suffixes
-%fontmetapkg
-
-%package   doc
-Summary:   %{name} optional documentation files
-BuildArch: noarch
-%description doc
-This package provides optional documentation files shipped with %{name}.
-
-%prep
-%setup
-%linuxtext *.txt
-
-%build
-# “fontbuild” accepts the usual selection arguments:
-# – “-a”          process everything
-# – “-z [number]” process a specific declaration block
-# If no flag is specified it will only process the zero/nosuffix block.
-%fontbuild -a
-
-%install
-# “fontinstall” accepts the usual selection arguments:
-# – “-a”          process everything
-# – “-z [number]” process a specific declaration block
-# If no flag is specified it will only process the zero/nosuffix block.
-%fontinstall -a
-
-%check
-# “fontcheck” accepts the usual selection arguments:
-# – “-a”          process everything
-# – “-z [number]” process a specific declaration block
-# If no flag is specified it will only process the zero/nosuffix block.
-%fontcheck -a
-
-# “fontfiles” accepts the usual selection arguments:
-# – “-a”          process everything
-# – “-z [number]” process a specific declaration block
-# If no flag is specified it will only process the zero/nosuffix block
-%fontfiles -a
-
-%files doc
-%license 
-%doc 
-
-%changelog
diff --git a/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-3-sub.spec b/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-3-sub.spec
deleted file mode 100644
index 061db1d..0000000
--- a/guidelines/modules/ROOT/examples/fonts/spectemplate-fonts-3-sub.spec
+++ /dev/null
@@ -1,108 +0,0 @@
-# Packaging template: packaging fonts, released as part of something else
-#
-# SPDX-License-Identifier: MIT
-#
-# This template documents spec declarations, used when packaging one or several
-# font families from a source rpm which is not named after the first packaged
-# font family:
-# – either because the project name differs from the main font family name
-# – or when the source archive and rpm are used to package more than fonts.
-#
-# It is part of the following set of packaging templates:
-# “fonts-0-simple”: basic single-family fonts packaging
-# “fonts-1-full”:   less common patterns for single-family fonts packaging
-# “fonts-2-multi”:  multi-family fonts packaging
-# “fonts-3-sub”:    packaging fonts, released as part of something else
-#
-# The packaging style is identical to the one documented in “fonts-2-multi”,
-# EXCEPT it should not use the zero/nosuffix declaration block, as this block
-# will attempt to generate source rpm declarations by default.
-#
-# Usually appropriate for fonts-only packages
-BuildArch: noarch
-
-Version: 
-Release: 
-License: 
-URL:     
-
-%global foundry           
-# If different from the main License
-%global fontlicense       
-%global fontlicenses      
-%global fontlicensesex    
-%global fontdocs          
-%global fontdocsex        %{fontlicenses}
-
-%global common_description %{expand:
-}
-
-%global fontfamily1       
-%global fontsummary1      
-%global fontpkgheader1    %{expand:
-}
-%global fonts1            
-%global fontsex1          
-%global fontconfs1        %{SOURCE11}
-%global fontconfsex1      
-%global fontappstreams1   
-%global fontappstreamsex1 
-%global fontdescription1  %{expand:
-%{common_description}
-Additional text…}
-
-%global fontfamily2       
-%global fontsummary2      
-%global fontpkgheader2    %{expand:
-}
-%global fonts2            
-%global fontsex2          
-%global fontconfs2        %{SOURCE12}
-%global fontconfsex2      
-%global fontappstreams2   
-%global fontappstreamsex2 
-%global fontdescription2  %{expand:
-%{common_description}
-Other Additional text…}
-#
-# Continue as necessary…
-
-Source0:  
-Source11: [number]-%{fontpkgname1}.conf
-Source12: [number]-%{fontpkgname2}.conf
-
-Name:     
-Summary:  
-%description
-%wordwrap -v common_description
-
-%fontpkg -a
-
-%fontmetapkg
-
-%package   doc
-Summary:   %{name} optional documentation files
-BuildArch: noarch
-%description doc
-This package provides optional documentation files shipped with %{name}.
-
-%prep
-%setup
-%linuxtext *.txt
-
-%build
-%fontbuild -a
-
-%install
-%fontinstall -a
-
-%check
-%fontcheck -a
-
-%fontfiles -a
-
-%files doc
-%license 
-%doc 
-
-%changelog
diff --git a/guidelines/modules/ROOT/examples/golang/golang-cloud-google-go.spec b/guidelines/modules/ROOT/examples/golang/golang-cloud-google-go.spec
deleted file mode 100644
index 5365be5..0000000
--- a/guidelines/modules/ROOT/examples/golang/golang-cloud-google-go.spec
+++ /dev/null
@@ -1,187 +0,0 @@
-# Generated by go2rpm
-%bcond_without check
-%bcond_without bootstrap
-
-# https://github.com/GoogleCloudPlatform/google-cloud-go
-%global goipath         cloud.google.com/go
-%global forgeurl        https://github.com/GoogleCloudPlatform/google-cloud-go
-Version:                0.37.4
-
-%gometa
-
-%if %{without bootstrap}
-%global goipaths0       cloud.google.com/go
-%global goipathsex0     cloud.google.com/go/compute
-%endif
-
-%global goipaths1       cloud.google.com/go/compute
-
-%global common_description %{expand:
-Go packages for Google Cloud Platform services.}
-
-%global golicenses      LICENSE
-%global godocs          AUTHORS CODE_OF_CONDUCT.md CONTRIBUTING.md CONTRIBUTORS RELEASING.md old-news.md CHANGES.md README.md
-
-Name:           %{goname}
-Release:        1%{?dist}
-Summary:        Google Cloud client libraries for Go
-
-# Upstream license specification: Apache-2.0
-License:        Apache-2.0
-URL:            %{gourl}
-Source:         %{gosource}
-
-%if %{without bootstrap}
-BuildRequires:  golang(github.com/golang/mock/gomock)
-BuildRequires:  golang(github.com/golang/protobuf/proto)
-BuildRequires:  golang(github.com/golang/protobuf/ptypes)
-BuildRequires:  golang(github.com/golang/protobuf/ptypes/any)
-BuildRequires:  golang(github.com/golang/protobuf/ptypes/duration)
-BuildRequires:  golang(github.com/golang/protobuf/ptypes/empty)
-BuildRequires:  golang(github.com/golang/protobuf/ptypes/struct)
-BuildRequires:  golang(github.com/golang/protobuf/ptypes/timestamp)
-BuildRequires:  golang(github.com/golang/protobuf/ptypes/wrappers)
-BuildRequires:  golang(github.com/google/btree)
-BuildRequires:  golang(github.com/google/go-cmp/cmp)
-BuildRequires:  golang(github.com/google/martian)
-BuildRequires:  golang(github.com/google/martian/fifo)
-BuildRequires:  golang(github.com/google/martian/httpspec)
-BuildRequires:  golang(github.com/google/martian/martianhttp)
-BuildRequires:  golang(github.com/google/martian/martianlog)
-BuildRequires:  golang(github.com/google/martian/mitm)
-BuildRequires:  golang(github.com/google/pprof/profile)
-BuildRequires:  golang(github.com/googleapis/gax-go/v2)
-BuildRequires:  golang(go.opencensus.io/plugin/ocgrpc)
-BuildRequires:  golang(go.opencensus.io/stats)
-BuildRequires:  golang(go.opencensus.io/stats/view)
-BuildRequires:  golang(go.opencensus.io/tag)
-BuildRequires:  golang(go.opencensus.io/trace)
-BuildRequires:  golang(golang.org/x/oauth2)
-BuildRequires:  golang(golang.org/x/oauth2/google)
-BuildRequires:  golang(golang.org/x/oauth2/jwt)
-BuildRequires:  golang(golang.org/x/sync/errgroup)
-BuildRequires:  golang(golang.org/x/sync/semaphore)
-BuildRequires:  golang(golang.org/x/text/language)
-BuildRequires:  golang(golang.org/x/time/rate)
-BuildRequires:  golang(google.golang.org/api/bigquery/v2)
-BuildRequires:  golang(google.golang.org/api/clouddebugger/v2)
-BuildRequires:  golang(google.golang.org/api/cloudresourcemanager/v1)
-BuildRequires:  golang(google.golang.org/api/cloudtrace/v1)
-BuildRequires:  golang(google.golang.org/api/compute/v1)
-BuildRequires:  golang(google.golang.org/api/container/v1)
-BuildRequires:  golang(google.golang.org/api/gensupport)
-BuildRequires:  golang(google.golang.org/api/googleapi)
-BuildRequires:  golang(google.golang.org/api/iterator)
-BuildRequires:  golang(google.golang.org/api/option)
-BuildRequires:  golang(google.golang.org/api/storage/v1)
-BuildRequires:  golang(google.golang.org/api/support/bundler)
-BuildRequires:  golang(google.golang.org/api/transport)
-BuildRequires:  golang(google.golang.org/api/transport/grpc)
-BuildRequires:  golang(google.golang.org/api/transport/http)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/api/expr/v1alpha1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/api/label)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/api/metric)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/api/monitoredres)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/appengine/logging/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/bigtable/admin/v2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/bigtable/v2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/asset/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/asset/v1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/audit)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/bigquery/datatransfer/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/bigquery/storage/v1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/dataproc/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/dataproc/v1beta2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/dialogflow/v2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/iot/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/irm/v1alpha2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/kms/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/language/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/language/v1beta2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/oslogin/common)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/oslogin/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/oslogin/v1beta)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/redis/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/redis/v1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/scheduler/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/scheduler/v1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/securitycenter/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/securitycenter/v1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/speech/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/speech/v1p1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/talent/v4beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/tasks/v2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/tasks/v2beta2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/tasks/v2beta3)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/texttospeech/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/videointelligence/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/videointelligence/v1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/videointelligence/v1beta2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/vision/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/vision/v1p1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/cloud/webrisk/v1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/container/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/datastore/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/devtools/clouddebugger/v2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/devtools/clouderrorreporting/v1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/devtools/cloudprofiler/v2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/devtools/cloudtrace/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/devtools/cloudtrace/v2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/devtools/containeranalysis/v1beta1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/devtools/containeranalysis/v1beta1/grafeas)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/firestore/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/iam/admin/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/iam/credentials/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/iam/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/logging/type)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/logging/v2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/longrunning)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/monitoring/v3)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/privacy/dlp/v2)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/pubsub/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/rpc/code)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/rpc/errdetails)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/rpc/status)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/spanner/admin/database/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/spanner/admin/instance/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/spanner/v1)
-BuildRequires:  golang(google.golang.org/genproto/googleapis/type/latlng)
-BuildRequires:  golang(google.golang.org/genproto/protobuf/field_mask)
-BuildRequires:  golang(google.golang.org/grpc)
-BuildRequires:  golang(google.golang.org/grpc/codes)
-BuildRequires:  golang(google.golang.org/grpc/credentials)
-BuildRequires:  golang(google.golang.org/grpc/keepalive)
-BuildRequires:  golang(google.golang.org/grpc/metadata)
-BuildRequires:  golang(google.golang.org/grpc/status)
-
-%if %{with check}
-# Tests
-BuildRequires:  golang(github.com/google/go-cmp/cmp/cmpopts)
-BuildRequires:  golang(google.golang.org/api/iterator/testing)
-BuildRequires:  golang(google.golang.org/api/logging/v2)
-%endif
-%endif
-
-%description
-%{common_description}
-
-%gopkg
-
-%prep
-%goprep
-
-%install
-%gopkginstall
-
-%if %{without bootstrap}
-%if %{with check}
-%check
-%gocheck
-%endif
-%endif
-
-%gopkgfiles
-
-%changelog
-* Tue Apr 23 09:48:52 CEST 2019 Robert-André Mauchin <zebob.m@gmail.com> - 0.37.4-1
-- Release 0.37.4
diff --git a/guidelines/modules/ROOT/examples/golang/golang-github-sirupsen-logrus.spec b/guidelines/modules/ROOT/examples/golang/golang-github-sirupsen-logrus.spec
deleted file mode 100644
index e83eaec..0000000
--- a/guidelines/modules/ROOT/examples/golang/golang-github-sirupsen-logrus.spec
+++ /dev/null
@@ -1,45 +0,0 @@
-# https://github.com/sirupsen/logrus
-%global goipath         github.com/sirupsen/logrus
-Version:                1.4.0
-
-%gometa
-
-%global goaltipaths     github.com/Sirupsen/logrus
-
-%global common_description %{expand:
-Logrus is a structured logger for Go (golang), completely API compatible with
-the standard library logger.}
-
-%global golicenses    LICENSE
-%global godocs        *.md
-
-Name:           %{goname}
-Release:        1%{?dist}
-Summary:        Structured logger for Go
-License:        MIT
-URL:            %{gourl}
-Source:         %{gosource}
-
-BuildRequires: golang(golang.org/x/crypto/ssh/terminal)
-BuildRequires: golang(github.com/stretchr/testify/assert)
-
-%description
-%{common_description}
-
-%gopkg
-
-%prep
-%goprep
-
-%install
-%gopkginstall
-
-%check
-%gocheck
-
-%gopkgfiles
-
-
-%changelog
-* Wed Oct 31 2018 Robert-André Mauchin <zebob.m@gmail.com> - 1.4.0-1
-- First package for Fedora
diff --git a/guidelines/modules/ROOT/examples/golang/golang-github-stretchr-testify.spec b/guidelines/modules/ROOT/examples/golang/golang-github-stretchr-testify.spec
deleted file mode 100644
index 59c9d08..0000000
--- a/guidelines/modules/ROOT/examples/golang/golang-github-stretchr-testify.spec
+++ /dev/null
@@ -1,49 +0,0 @@
-# https://github.com/stretchr/testify
-%global goipath         github.com/stretchr/testify
-Version:                1.2.2
-
-%gometa
-
-%global common_description %{expand:
-Golang set of packages that provide many tools for testifying
-that your code will behave as you intend.
-
-Features include:
-
- - Easy assertions
- - Mocking
- - Testing suite interfaces and functions}
-
-%global golicenses    LICENSE
-
-Name:           %{goname}
-Release:        1%{?dist}
-Summary:        Tools for testifying that your code will behave as you intend
-License:        MIT
-URL:            %{gourl}
-Source:         %{gosource}
-
-BuildRequires: golang(github.com/davecgh/go-spew/spew)
-BuildRequires: golang(github.com/pmezard/go-difflib/difflib)
-BuildRequires: golang(github.com/stretchr/objx)
-
-%description
-%{common_description}
-
-%gopkg
-
-%prep
-%goprep
-
-%install
-%gopkginstall
-
-%check
-%gocheck
-
-%gopkgfiles
-
-
-%changelog
-* Thu Mar 21 22:20:22 CET 2019 Robert-André Mauchin <zebob.m@gmail.com> - 1.2.2-1
-- First package for Fedora
diff --git a/guidelines/modules/ROOT/examples/golang/golang-gopkg-square-jose-2.spec b/guidelines/modules/ROOT/examples/golang/golang-gopkg-square-jose-2.spec
deleted file mode 100644
index 40250d7..0000000
--- a/guidelines/modules/ROOT/examples/golang/golang-gopkg-square-jose-2.spec
+++ /dev/null
@@ -1,67 +0,0 @@
-# https://github.com/square/go-jose
-%global goipath         gopkg.in/square/go-jose.v2
-%global forgeurl        https://github.com/square/go-jose
-Version:                2.1.9
-
-%gometa
-
-%global common_description %{expand:
-Package jose aims to provide an implementation of the Javascript Object
-Signing and Encryption set of standards. This includes support for JSON Web
-Encryption, JSON Web Signature, and JSON Web Token standards.}
-
-%global golicenses    LICENSE
-%global godocs        *.md
-
-%global godevelheader %{expand:
-# The devel package will usually benefit from corresponding project binaries.
-Requires:  %{name} = %{version}-%{release}
-}
-
-Name:           %{goname}
-Release:        1%{?dist}
-Summary:        An implementation of JOSE standards (JWE, JWS, JWT) in Go
-# Detected licences
-# - *No copyright* Apache License (v2.0) at 'LICENSE'
-# json/ is BSD-3-Clause
-License:        Apache-2.0 AND BSD-3-Clause
-URL:            %{gourl}
-Source:         %{gosource}
-
-BuildRequires: golang(golang.org/x/crypto/ed25519)
-BuildRequires: golang(golang.org/x/crypto/pbkdf2)
-BuildRequires: golang(github.com/stretchr/testify/assert)
-BuildRequires: golang(gopkg.in/alecthomas/kingpin.v2)
-
-%description
-%{common_description}
-
-%gopkg
-
-%prep
-%goprep
-
-%build
-for cmd in jose-util jwk-keygen; do
-  %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
-done
-
-%install
-%gopkginstall
-install -m 0755 -vd                     %{buildroot}%{_bindir}
-install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/
-
-%check
-%gocheck
-
-%files
-%license %{golicenses}
-%doc %{godocs}
-%{_bindir}/*
-
-%gopkgfiles
-
-%changelog
-* Thu Mar 21 21:59:10 CET 2019 Robert-André Mauchin <zebob.m@gmail.com> - 2.1.9-1
-- First package for Fedora
-
diff --git a/guidelines/modules/ROOT/examples/golang/spectemplate-go-0-source-minimal.spec b/guidelines/modules/ROOT/examples/golang/spectemplate-go-0-source-minimal.spec
deleted file mode 100644
index ac1266c..0000000
--- a/guidelines/modules/ROOT/examples/golang/spectemplate-go-0-source-minimal.spec
+++ /dev/null
@@ -1,140 +0,0 @@
-# Minimal Go source code packaging template.
-#
-# This template documents the minimal set of spec declarations, necessary to
-# publish Go source code to other packages. The sister “go-1-source-full”
-# template documents less common declarations; read it if your needs exceed
-# this file.
-#
-# All the “go-*-” spec templates complement one another without documentation
-# overlaps. Try to read them all.
-#
-# The master Go import path of the project. Take the time to identify it
-# accurately, changing it later will be inconvenient:
-#  – it may differ from the repository URL;
-#  – generally, the correct value will be the one used by the project in its
-#    documentation, coding examples, and build assertions;
-#  – use the gopkg import path for all code states when a project uses it.
-# If upstream confused itself after multiple forks and renamings, you need to
-# fix references to past names in the Go source files, unit tests included.
-# Perform this fixing in “prep”.
-%global goipath  
-#
-# “gometa” is a thin Go-specific wrapper around “forgemeta”. Therefore, define
-# “version”, “tag”, “commit”… before the “gometa” line, as you would with
-# “forgemeta”. Only define the rpm variables actually needed by the spec file.
-#  – define “forgeurl”, including “https://” prefixing, if the import path
-#    does not match the repository URL; otherwise it is not necessary,
-%global forgeurl 
-#  – move the Version: line before the “gometa” call if you are packaging a
-#    release.
-Version:         
-%global tag      
-%global commit   
-#
-# Like “forgemeta”, “gometa” accepts a “-i” flag to output the rpm variables it
-# reads and sets. Most of those can be overriden before or after the “gometa”
-# call. If you use “-i” , remove it before committing and pushing to the
-# buildsystem.
-# See the “forge” spec templates for detailed “forgemeta” documentation.
-%gometa
-
-# A space-separated list of shell globs matching the project license files.
-%global golicenses      
-# A space-separated list of shell globs matching the project documentation files.
-# The Go rpm macros will pick up “.md” files by default without this.
-%global godocs          
-
-# A multiline description block shared between subpackages
-%global common_description %{expand:
-}
-
-# The following lines use “go*” variables computed by gometa as default values.
-# You can replace them with manual definitions. For example, replace “gourl”
-# with the project homepage if it exists separately from the repository URL. Be
-# careful to only replace “go*” variables when it adds value to the specfile
-# and you understand the consequences. Otherwise you will just add
-# maintenance-intensive discrepancies in the distribution.
-Name:    %{goname}
-# If not set before
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:     %{gourl}
-Source:  %{gosource}
-%description
-%{common_description}
-
-# Generate package declarations for all known kinds of Go subpackages.
-# You can replace if with “godevelpkg” to generate Go devel subpackages only.
-%gopkg
-
-%prep
-# “goprep” unpacks the Go source archives and creates the project “GOPATH” tree
-# used in the rest of the spec file. It removes vendored (bundled) code:
-#  – use the “-k” flag if you wish to keep this vendored code, and deal with the
-#    consequences in the rest of the spec.
-#  – use the “-e” flag if you wish to perform extraction yourself, and just use
-#    the “GOPATH” creation logic.
-%goprep
-#
-# “goprep” only performs basic vendoring detection. It will miss inventive ways
-# to vendor code. Remove manually missed vendor code, after the “goprep” line.
-# “goprep” will not fix upstream sources for you. Since all the macro calls that
-# follow “goprep” assume clean problem-free sources, you need to correct them
-# just after the “goprep” line:
-#  – replace calls to deprecated import paths with their correct value
-#  – patch code problems
-#  – remove dead code (some upstreams deliberately ship broken source code in
-#    the hope someone will get around to fix it)
-# Remember to send fixes and problem reports upstream.
-# When you package an import path, that participates in a dependency loop, you
-# need bootstraping to manage the initial builds:
-# https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
-# For Go code, that means your bootstrap section should:
-#  – remove unit tests that import other parts of the loop
-#  – remove code that imports other parts of the loop
-# Sometimes one can resolve dependency loops just by splitting specific
-# subdirectories in a separate -devel subpackage. See also the “go-6-multi”
-# template.
-#
-
-# Anything outputed in this rpm section will be installed in the build
-# environment by mock
-%generate_buildrequires
-# “go_generate_buildrequires” computes the build dependencies of the packaged
-# Go code. Right now, it only knows how to compute version-less dependencies.
-# If that is not good enough for you you need to filter and rework its output.
-%go_generate_buildrequires
-
-%install
-# Perform installation steps for all known kinds of Go subpackages
-# You can replace if with “godevelinstall” to process Go devel subpackages only
-%gopkginstall
-
-%check
-# “gocheck” runs all the unit tests found in the project. This is useful to catch
-# API breakage early. Unfortunately, the following kinds of unit tests are
-# incompatible with a secure build environment:
-#  – tests that call a remote server or API over the Internet,
-#  – tests that attempt to reconfigure the system,
-#  – tests that rely on a specific app running on the system, like a database
-#    or syslog server.
-# You can disable those tests with the following exclusion flags, that can be
-# repeated:
-#  – “-d <directory>”     exclude the files contained in <directory>
-#                         not recursive (subdirectories are not excluded)
-#  – “-t <tree root>”     exclude the files contained in <tree root>
-#                         recursive (subdirectories are excluded)
-#  – “-r <regexp>”        exclude files matching <regexp>,
-# If a test is broken for some other reason, you can disable it
-# the same way. However, you should also report the problem upstream.
-# Remember to trace in a comment why each check was disabled, with links to
-# eventual upstream problem reports.
-%gocheck
-
-# Generate file sections for all known kinds of Go subpackages
-# You can replace if with “godevelfiles” to process Go devel subpackages only
-%gopkgfiles
-
-%changelog
-
diff --git a/guidelines/modules/ROOT/examples/golang/spectemplate-go-1-source-full.spec b/guidelines/modules/ROOT/examples/golang/spectemplate-go-1-source-full.spec
deleted file mode 100644
index 8b7ec9b..0000000
--- a/guidelines/modules/ROOT/examples/golang/spectemplate-go-1-source-full.spec
+++ /dev/null
@@ -1,104 +0,0 @@
-# Complete Go source code packaging template.
-#
-# This template complements “go-0-source-minimal”, with less usual spec
-# declarations.
-#
-# All the “go-*-” spec templates complement one another without documentation
-# overlaps. Try to read them all.
-#
-%global goipath  
-Version:         
-%global tag      
-%global commit   
-#
-# A compatibility id that should be used in the package naming. It will change
-# the generated “goname” to something derived from
-# compat-golang-goipath-gocid-devel.
-# “gocids” are used to disambiguate compatibility packages from the package
-# tracking the recommended distribution version. Usual values:
-#  – the version major (if different),
-#  – a shortened commit tag such as
-#    %{lua:print(string.sub(rpm.expand("%{?commit}"), 1, 7))}
-%global gocid    
-%gometa
-
-# rpm variables used to tweak the generated golang-*devel package.
-# Most of them won’t be needed by the average Go spec file.
-#
-# A space-separated list of Go import paths to include. Unless specified
-# otherwise the first element in the list will be used to name the subpackage.
-# (by default, “goipath”)
-%global goipaths        
-# A space-separated list of Go import paths to exclude. Usually, subsets of the
-# elements in goipaths.
-%global goipathsex      
-# A compatibility id that should be used in the package naming.
-# (by default, “gocid”)
-%global godevelcid      
-# A value that will replace the computed subpackage name.
-# (by default “gorpmname-devel”)
-%global godevelname     
-# The subpackage summary.
-# (by default, “summary”)
-%global godevelsummary  
-# A container for additional subpackage declarations.
-%global godevelheader %{expand:
-Requires:  
-Obsoletes: 
-}
-# The subpackage base description.
-# (by default, “common_description”)
-%global godeveldescription %{expand:
-}
-%global golicenses      
-# A space-separated list of shell globs matching files you wish to exclude from
-# license lists.
-%global golicensesex    
-%global godocs          
-# A space-separated list of shell globs matching files you wish to exclude from
-# documentation lists. Only works for “godocs”-specified files.
-%global godocsex        
-# A space separated list of extentions that should be included in the devel
-# package in addition to Go default file extensions.
-%global goextensions    
-# A space-separated list of shell globs matching other files to include in the
-# devel package.
-%global gosupfiles      
-# A space-separated list of shell globs matching other files ou wish to exclude from
-# package lists. Only works with “gosupfiles”-specified files.
-%global gosupfilesex    
-# The filelist name associated with the subpackage. Setting this should never
-# be necessary unless the default name clashes with something else.
-%global godevelfilelist 
-
-%global common_description %{expand:
-}
-
-Name:    %{goname}
-# If not set before
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:     %{gourl}
-Source:  %{gosource}
-%description
-%{common_description}
-
-%gopkg
-
-%prep
-%goprep
-
-%generate_buildrequires
-%go_generate_buildrequires
-
-%install
-%gopkginstall
-
-%check
-%gocheck
-
-%gopkgfiles
-
-%changelog
-
diff --git a/guidelines/modules/ROOT/examples/golang/spectemplate-go-2-alternative-import-path-minimal.spec b/guidelines/modules/ROOT/examples/golang/spectemplate-go-2-alternative-import-path-minimal.spec
deleted file mode 100644
index 72ba86a..0000000
--- a/guidelines/modules/ROOT/examples/golang/spectemplate-go-2-alternative-import-path-minimal.spec
+++ /dev/null
@@ -1,69 +0,0 @@
-# Minimal Go alternative import path packaging template.
-#
-# Sometimes Go projects keep importing deprecated import path names, or use
-# forks with different names. Ideally, all codebases should be fixed to use the
-# current canonical import path, but that is not always possible.
-#
-# This template documents the minimal set of spec declarations, necessary to
-# publish alternative Go import paths to other packages. The sister
-# “go-3-alternative import-path-full” template documents less common
-# declarations; read it if your needs exceed this file.
-#
-# All the “go-*-” spec templates complement one another without documentation
-# overlaps. Try to read them all.
-#
-# Simulating other import paths prevents the duplicate packaging of the a
-# codebase when packagers do not notice an import path has been renamed. It
-# keeps spec files that refer to the old name working. Those should still be
-# fixed to use the new name as soon as possible.
-#
-%global goipath  
-Version:         
-%global tag      
-%global commit   
-%gometa
-
-%global golicenses      
-%global godocs          
-
-# A space-separated list of import paths to simulate. Without this nothing will
-# happen.
-%global goaltipaths     
-
-%global common_description %{expand:
-}
-
-Name:    %{goname}
-# If not set before
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:     %{gourl}
-Source:  %{gosource}
-%description
-%{common_description}
-
-# Generate package declarations for all known kinds of Go subpackages. You can
-# replace if with separate “goaltpkg” and “godevelpkg” calls.
-%gopkg
-
-%prep
-%goprep
-
-%generate_buildrequires
-%go_generate_buildrequires
-
-%install
-# Perform installation steps for all known kinds of Go subpackages. You can
-# replace if with separate “goaltinstall” and “godevelinstall” calls.
-%gopkginstall
-
-%check
-%gocheck
-
-# Generate file sections for all known kinds of Go subpackages. You can replace
-# if with separate “goaltfiles” and “godevelfiles” calls.
-%gopkgfiles
-
-%changelog
-
diff --git a/guidelines/modules/ROOT/examples/golang/spectemplate-go-3-alternative-import-path-full.spec b/guidelines/modules/ROOT/examples/golang/spectemplate-go-3-alternative-import-path-full.spec
deleted file mode 100644
index 58d75bd..0000000
--- a/guidelines/modules/ROOT/examples/golang/spectemplate-go-3-alternative-import-path-full.spec
+++ /dev/null
@@ -1,89 +0,0 @@
-# Complete Go alternative import path packaging template.
-#
-# This template complements “go-2-alternative import-path-minimal”, with less
-# usual spec declarations.
-#
-# All the “go-*-” spec templates complement one another without documentation
-# overlaps. Try to read them all.
-#
-%global goipath  
-%global forgeurl 
-Version:         
-%global tag      
-%global commit   
-%global gocid    
-%gometa
-
-%global goipaths        
-%global goipathsex      
-%global godevelcid      
-%global godevelname     
-%global godevelsummary  
-%global godevelheader %{expand:
-Requires:  
-Obsoletes: 
-}
-%global golicenses      
-%global golicensesex    
-%global godocs          
-%global godocsex        
-%global goextensions    
-%global gosupfiles      
-%global gosupfilesex    
-%global godevelfilelist 
-
-%global goaltipaths     
-#
-# rpm variables used to tweak the generated compat-golang-*devel packages.
-# Most of them won’t be needed by the average Go spec file.
-#
-# The import path that will be linked to.
-# (by default, “goipath”)
-%global gocanonipath    
-# A compatibility id that should be used in the package naming.
-# (by default, “gocid”)
-%global goaltcid        
-# The subpackage summary;
-# (by default, “summary”)
-%global goaltsummary    
-# A container for additional subpackage declarations.
-%global goaltheader      %{expand:
-Requires:  
-Obsoletes: 
-}
-# The subpackage base description;
-# (by default, “common_description”)
-%global goaltdescription %{expand:
-}
-
-%global common_description %{expand:
-}
-
-Name:    %{goname}
-# If not set before
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:     %{gourl}
-Source:  %{gosource}
-%description
-%{common_description}
-
-%gopkg
-
-%prep
-%goprep
-
-%generate_buildrequires
-%go_generate_buildrequires
-
-%install
-%gopkginstall
-
-%check
-%gocheck
-
-%gopkgfiles
-
-%changelog
-
diff --git a/guidelines/modules/ROOT/examples/golang/spectemplate-go-4-binary-minimal.spec b/guidelines/modules/ROOT/examples/golang/spectemplate-go-4-binary-minimal.spec
deleted file mode 100644
index c578324..0000000
--- a/guidelines/modules/ROOT/examples/golang/spectemplate-go-4-binary-minimal.spec
+++ /dev/null
@@ -1,79 +0,0 @@
-# Minimal Go binary packaging template.
-#
-# This template documents the minimal set of spec declarations, necessary to
-# package Go projects that produce binaries. The sister “go-5-binary-full”
-# template documents less common declarations; read it if your needs exceed
-# this file.
-#
-# All the “go-*-” spec templates complement one another without documentation
-# overlaps. Try to read them all.
-#
-# Building Go binaries is less automated than the rest of our Go packaging and
-# requires more manual work.
-#
-%global goipath  
-Version:         
-%global tag      
-%global commit   
-%gometa
-
-%global _docdir_fmt     %{name}
-
-%global golicenses      
-%global godocs          
-%global godevelheader %{expand:
-# The devel package will usually benefit from corresponding project binaries.
-Requires:  %{name} = %{version}-%{release}
-Obsoletes:
-}
-
-%global common_description %{expand:
-}
-
-# If one of the produced binaries is widely known it should be used to name the
-# package instead of “goname”. Separate built binaries in different subpackages
-# if needed.
-Name:    %{goname}
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:     %{gourl}
-Source:  %{gosource}
-%description
-%{common_description}
-
-%gopkg
-
-%prep
-%goprep
-
-%generate_buildrequires
-%go_generate_buildrequires
-
-%build
-# You need to identify manually the project parts that can be built, and how to
-# name the result. Practically, it’s any directory containing a main() Go
-# section. Nice projects put those in “cmd” subdirectories named after the
-# command that will be built, which is what we will document here, but it is
-# not a general rule. Sometimes the whole “goipath” builds as a single binary.
-for cmd in cmd/* ; do
-  %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
-done
-
-%install
-%gopkginstall
-install -m 0755 -vd                     %{buildroot}%{_bindir}
-install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/
-
-%check
-%gocheck
-
-%files
-%license %{golicenses}
-%doc     
-%{_bindir}/*
-
-%gopkgfiles
-
-%changelog
-
diff --git a/guidelines/modules/ROOT/examples/golang/spectemplate-go-5-binary-full.spec b/guidelines/modules/ROOT/examples/golang/spectemplate-go-5-binary-full.spec
deleted file mode 100644
index c98b731..0000000
--- a/guidelines/modules/ROOT/examples/golang/spectemplate-go-5-binary-full.spec
+++ /dev/null
@@ -1,91 +0,0 @@
-# Complete Go binary packaging template.
-#
-# This template complements “go-5-binary-minimal”, with less usual spec
-# declarations.
-#
-# All the “go-*-” spec templates complement one another without documentation
-# overlaps. Try to read them all
-#
-%global goipath  
-%global forgeurl 
-Version:         
-%global tag      
-%global commit   
-%global gocid    
-%gometa
-
-%global _docdir_fmt     %{name}
-
-%global goipaths        
-%global goipathsex      
-%global godevelcid      
-%global godevelname     
-%global godevelsummary  
-%global godevelheader %{expand:
-Requires:  %{name} = %{version}-%{release}
-Obsoletes: 
-}
-%global golicenses      
-%global golicensesex    
-%global godocs          
-%global godocsex        
-%global goextensions    
-%global gosupfiles      
-%global gosupfilesex    
-%global godevelfilelist 
-
-%global goaltipaths     
-%global gocannonipath   
-%global goaltcid        
-%global goaltsummary    
-%global goaltheader      %{expand:
-Requires:  
-Obsoletes: 
-}
-%global goaltdescription %{expand:
-}
-
-%global common_description %{expand:
-}
-
-
-Name:    %{goname}
-# If not set before
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:     %{gourl}
-Source:  %{gosource}
-%description
-%{common_description}
-
-%gopkg
-
-%prep
-%goprep
-
-%generate_buildrequires
-%go_generate_buildrequires
-
-%build
-for cmd in cmd/* ; do
-  %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
-done
-
-%install
-%gopkginstall
-install -m 0755 -vd                     %{buildroot}%{_bindir}
-install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/
-
-%check
-%gocheck
-
-%files
-%license %{golicenses}
-%doc     
-%{_bindir}/*
-
-%gopkgfiles
-
-%changelog
-
diff --git a/guidelines/modules/ROOT/examples/golang/spectemplate-go-6-multi.spec b/guidelines/modules/ROOT/examples/golang/spectemplate-go-6-multi.spec
deleted file mode 100644
index 198eb63..0000000
--- a/guidelines/modules/ROOT/examples/golang/spectemplate-go-6-multi.spec
+++ /dev/null
@@ -1,193 +0,0 @@
-# This template documents advanced Go packaging with multiples of everything.
-# Don’t try it before you understand how simpler Go packaging is done.
-#
-# All the “go-*-” spec templates complement one another without documentation
-# overlaps. Try to read them all.
-#
-# Don’t hesitate to use “rpmspec -P <specfile>” to check the generated code.
-#
-# You can refer to several upstream archives using the “-a” “gometa” flag and
-# blocks of declarations suffixed by a block number, like with “forgemeta”.
-# No suffix or zero suffix refers to the main archive. Refer to the forge-multi
-# template for more detailed information.
-# IT IS A TERRIBLE IDEA TO TRY THIS UNLESS EVERY SOURCE ARCHIVE IS PERFECTLY
-# VERSION-LOCKED WITH THE OTHERS. That will produce broken rpm versionning and
-# broken upgrade paths. It is always simpler and safer to package separate
-# projects with separate spec files.
-#
-# Main archive
-%global goipath0  
-%global forgeurl0 
-Version:          
-%global tag0      
-%global commit0   
-%global gocid0    
-#
-# Second archive
-%global goipath1  
-%global forgeurl1 
-%global version1  
-%global tag1      
-%global commit1   
-%global gocid1    
-#
-# Continue as necessary…
-#
-# Alternatively, you can use the “-z <number>” “gometa” argument to process a
-# specific declaration block only.
-%gometa -a
-
-%global _docdir_fmt     %{name}
-
-# Likewise, you can declare several devel subpackages, either one by source
-# archive or with any other import path layout.
-#
-# First golang-*-devel subpackage.
-#
-# If unset, and no “goipaths<number>” is defined in the spec, fallbacks to
-# “goipath<number>”
-%global goipaths0        
-%global goipathsex0      
-%global godevelcid0      
-%global godevelname0     
-%global godevelsummary0  
-%global godevelheader0 %{expand:
-Requires:  
-Obsoletes: 
-}
-%global golicenses0      
-%global golicensesex0    
-%global godocs0          
-%global godocsex0        
-%global goextensions0    
-%global gosupfiles0      
-%global gosupfilesex0    
-%global godevelfilelist0 
-#
-# Second golang-*-devel subpackage.
-%global goipaths1        
-%global goipathsex1      
-%global godevelcid1      
-%global godevelname1     
-%global godevelsummary1  
-%global godevelheader1 %{expand:
-Requires:  
-Obsoletes: 
-}
-%global golicenses1      
-%global golicensesex1    
-%global godocs1          
-%global godocsex1        
-%global goextensions1    
-%global gosupfiles1      
-%global gosupfilesex1    
-%global godevelfilelist1 
-#
-# Continue as necessary…
-
-
-# Likewise, you can declare several alternative name sets that will generate
-# the corresponding compat-golang-*-devel subpackages
-#
-# First compat-golang-*-devel subpackage set.
-%global goaltipaths0      
-# If unset, and no “gocanonipath<number>” is defined in the spec, fallbacks to
-# “goipath<number>”
-%global gocanonipath0     
-%global goaltsummary0     
-%global goaltheader0      %{expand:
-Requires:  
-Obsoletes: 
-}
-%global goaltdescription0 %{expand:
-}
-#
-# Second compat-golang-*-devel subpackage set.
-%global goaltipaths1      
-%global gocanonipath1     
-%global goaltsummary1     
-%global goaltheader1      %{expand:
-Requires:  
-Obsoletes: 
-}
-%global goaltdescription1 %{expand:
-}
-#
-# Continue as necessary…
-
-%global common_description %{expand:
-}
-
-# Use usual naming rules when generating binaries.
-Name:    %{goname}
-# If not set before
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:	 %{gourl}
-# One for each of the previous goipath blocks
-Source0: %{gosource0}
-Source1: %{gosource1}
-# …
-%description
-%{common_description}
-
-# “gopkg” will generate all the subpackages package declarations corresponding
-# to the elements declared above.
-# You can replace “gopkg” with “godevelpkg” and “goaltpkg” calls for finer
-# control.
-# “godevelpkg” and “goaltpkg” accept the usual selection arguments:
-# – “-a”          process everything
-# – “-z <number>” process a specific declaration block
-# If no flag is specified they only process the zero/nosuffix block.
-%gopkg
-
-%prep
-# “%goprep” and “go_generate_buildrequires” accept the usual selection arguments:
-# – “-a”          process everything
-# – “-z <number>” process a specific declaration block
-# If no flag is specified they only process the zero/nosuffix block.
-%goprep -a
-
-%generate_buildrequires
-%go_generate_buildrequires -a
-
-%build
-# When your spec processes multiple Go source archives, you need to call
-# “goenv” with the correct “-z <number>” argument before invoquing “%gobuild”.
-# Otherwise the binaries risk being built with parameters corresponding to
-# another source archive.
-for cmd in cmd/* ; do
-  %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
-done
-
-%install
-# You can replace “gopkginstall” with  “godevelinstall” and “goaltinstall”
-# calls for finer control.
-# “godevelinstall” and “goaltinstall” accept the usual selection arguments:
-# – “-a”          process everything
-# – “-z <number>” process a specific declaration block
-# If no flag is specified they only process the zero/nosuffix block.
-%gopkginstall
-
-install -m 0755 -vd                     %{buildroot}%{_bindir}
-install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/
-
-%check
-%gocheck
-
-%files
-%license 
-%doc     
-%{_bindir}/*
-
-# You can replace “gopkgfiles” with  “godevelfiles” and  “goaltfiles”
-# calls for finer control.
-# “godevelfiles” and “goaltfiles” accept the usual selection arguments:
-# – “-a”          process everything
-# – “-z <number>” process a specific declaration block
-# If no flag is specified they only process the zero/nosuffix block.
-%gopkgfiles
-
-%changelog
-
diff --git a/guidelines/modules/ROOT/examples/golang/spectemplate-go-7-manual.spec b/guidelines/modules/ROOT/examples/golang/spectemplate-go-7-manual.spec
deleted file mode 100644
index a524b72..0000000
--- a/guidelines/modules/ROOT/examples/golang/spectemplate-go-7-manual.spec
+++ /dev/null
@@ -1,145 +0,0 @@
-# This template documents old-style semi-manual Go packaging. This packaging
-# mode provides the most packager control. However, the result is also more
-# difficult to get right and to maintain.
-#
-# Using this packaging mode is not recommended unless you really need it. If
-# you prepare your sources correctly in prep you should not need it.
-#
-# All the “go-*-” spec templates complement one another without documentation
-# overlaps. Try to read them all..
-#
-%global goipath  
-%global forgeurl 
-Version:         
-%global tag      
-%global commit   
-%gometa
-
-# Old naming of the same project
-%global oldgoipath xxxx
-%global oldgoname  %gorpmname %{oldgoipath}
-
-%global common_description %{expand:
-}
-
-Name:    %{goname}
-# If not set before
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:     %{gourl}
-Source:  %{gosource}
-%description
-%{common_description}
-
-%package -n %{goname}-devel
-Summary: %{summary}
-
-# If the package builds some binaries
-Requires:  %{name} = %{version}-%{release}
-
-%description -n %{goname}-devel
-%{common_description}
-
-This package contains the source code needed for building packages that
-reference the following Go import paths:
- –  %{goipath}
-
-# If you’ve defined an alternative go name
-%package -n compat-%{oldgoname}-devel
-Summary:   %{summary}
-Obsoletes: %{oldgoname}-devel < %{version}-%{release}
-
-%description -n compat-%{oldgoname}-devel
-%{common_description}
-
-This package provides symbolic links that alias the following Go import paths
-to %{goipath}:
- – %{oldgoipath}
-
-Aliasing Go import paths via symbolic links or http redirects is fragile. If
-your Go code depends on this package, you should patch it to import directly
-%{goipath}.
-
-%prep
-%goprep
-
-%generate_buildrequires
-%go_generate_buildrequires
-
-%install
-# goinstall is our Go source installation workhorse. It accepts a huge and
-# bewildering array of arguments. Most of those have good default values,
-# changing them is more likely to compound existing spec problems than fix
-# anything.
-#
-# Selection arguments, that can not be repeated:
-#  – “-a”                  process everything
-#  – “-z <number>”         process a specific declaration block
-#  – “-i <go import path>” use the specified import path value
-#                          default: %{goipath<number>}
-#
-# If no “-a”, “-z” or “-i ”flag is specified goinstall will only process the
-# zero/nosuffix Go import path.
-#
-# Miscellaneous settings:
-#  – “-b <bindir>”         read binaries already produced in <bindir>
-#                          default: %{gobuilddir}/bin
-#  – “-s <sourcedir>”      read expanded and prepared Go sources in
-#                          <sourcedir>/src
-#                          <sourcedir> should be populated in %prep
-#                          default: %{gobuilddir}
-#  – “-o <filename>”       output installed file list in <filename>
-#                          default: %{gofilelist<number>}
-#  – “-O <directory>”      output <filename> in <directory>
-#  – “-l <ldflags>”        add those flags to LDFLAGS when building unit tests
-#  – “-v”                  be verbose
-#
-# Inclusion arguments, that can be repeated:
-#  – “-e <extension>”      include files with the provided extension
-#
-# Exclusion ar²guments, that can be repeated, relative to the go import path
-# root:
-#  – “-d <directory>”      exclude the files contained in <directory>
-#                          not recursive (subdirectories are not excluded)
-#  – “-t <tree root>”      exclude the files contained in <tree root>
-#                          recursive (subdirectories are excluded)
-#  – “-r <regexp>”         exclude files matching <regexp>,
-#
-# Optional versionning metadata, that can not be repeated:
-#  – “-V <version>”        should only be specified when creating subpackages
-#                          with distinct versions. Excellent tool for producing
-#                          broken packages.
-#                          default: %{version}.%{release}
-#  – “-T <tag>”            default: %{tag<number>}
-#  – “-C <commit>”         default: %{commit<number>}
-#  – “-B <branch>”         default: %{branch<number>}
-#
-%goinstall
-#
-# Old name aliasing
-install -m 0755 -vd %{buildroot}%{gopath}/src/%(dirname %{oldgoipath})
-ln -s %{gopath}/src/%{goipath} %{buildroot}%{gopath}/src/%{oldgoipath}
-#
-install -m 0755 -vd                     %{buildroot}%{_bindir}
-install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/
-
-%check
-%gocheck
-
-%files
-%license 
-%{_bindir}/*
-
-%files -n %{goname}-devel -f %{gofilelist}
-
-%files -n compat-%{oldgoname}-devel
-# You need as many of those as necessary to own the levels of directories
-# between %{gopath}/src and %{gopath}/src/%{oldgoipath}, that are not already
-# owned by the %{goname}-devel subpackage
-%dir %{gopath}/src/%(dirname %(dirname %{oldgoipath}))
-%dir %{gopath}/src/%(dirname %{oldgoipath})
-%{gopath}/src/%{oldgoipath}
-
-%changelog
-
diff --git a/guidelines/modules/ROOT/examples/haskell-binary-library.spec b/guidelines/modules/ROOT/examples/haskell-binary-library.spec
deleted file mode 100644
index de7a496..0000000
--- a/guidelines/modules/ROOT/examples/haskell-binary-library.spec
+++ /dev/null
@@ -1,81 +0,0 @@
-%global pkg_name @PACKAGE@
-
-Name:           %{pkg_name}
-Version:        @VERSION@
-Release:        1%{?dist}
-Summary:        @SUMMARY@
-
-License:        @LICENSE@
-URL:            https://hackage.haskell.org/package/%{name}
-Source:         https://hackage.haskell.org/package/%{name}-%{version}/%{name}-%{version}.tar.gz
-
-BuildRequires:  ghc-Cabal-devel
-BuildRequires:  ghc-rpm-macros
-BuildRequires:  ghc-base-prof
-
-%description
-@DESCRIPTION@
-
-
-%package -n ghc-%{name}
-Summary:        Haskell %{name} library
-
-%description -n ghc-%{name}
-This package contains the Haskell %{name} library.
-
-
-%package -n ghc-%{name}-devel
-Summary:        Haskell %{name} library development files
-Requires:       ghc-compiler = %{ghc_version}
-Requires:       ghc-%{name} = %{version}-%{release}
-
-%description -n ghc-%{name}-devel
-This package provides the Haskell %{pkg_name} library development files.
-
-
-%package -n ghc-%{name}-doc
-Summary:        Haskell %{pkg_name} library documentation
-BuildArch:      noarch
-
-%description -n ghc-%{name}-doc
-This package provides the Haskell %{pkg_name} library documentation.
-
-
-%package -n ghc-%{name}-prof
-Summary:        Haskell %{pkg_name} profiling library
-Requires:       ghc-%{name}-devel%{?_isa} = %{version}-%{release}
-Supplements:    (ghc-%{name}-devel and ghc-prof)
-
-%description -n ghc-%{name}-prof
-This package provides the Haskell %{pkg_name} profiling library.
-
-
-%prep
-%setup -q
-
-
-%build
-%ghc_lib_build
-
-
-%install
-%ghc_lib_install
-
-
-%files
-%license LICENSE
-%{_bindir}/%{name}
-
-
-%files -n ghc-%{name} -f ghc-%{name}.files
-%license LICENSE
-
-
-%files -n ghc-%{name}-devel -f ghc-%{name}-devel.files
-
-
-%files -n ghc-%{name}-doc -f ghc-%{name}-doc.files
-%license LICENSE
-
-
-%files -n ghc-%{name}-prof -f ghc-%{name}-prof.files
diff --git a/guidelines/modules/ROOT/examples/haskell-binary-only.spec b/guidelines/modules/ROOT/examples/haskell-binary-only.spec
deleted file mode 100644
index 28b0421..0000000
--- a/guidelines/modules/ROOT/examples/haskell-binary-only.spec
+++ /dev/null
@@ -1,32 +0,0 @@
-Name:           @PACKAGE@
-Version:        @VERSION@
-Release:        1%{?dist}
-Summary:        @SUMMARY@
-
-License:        @LICENSE@
-URL:            https://hackage.haskell.org/package/%{name}
-Source:         https://hackage.haskell.org/package/%{name}-%{version}/%{name}-%{version}.tar.gz
-
-BuildRequires:  ghc-Cabal-devel
-BuildRequires:  ghc-rpm-macros
-BuildRequires:  ghc-base-static
-
-%description
-@DESCRIPTION@
-
-
-%prep
-%setup -q
-
-
-%build
-%ghc_bin_build
-
-
-%install
-%ghc_bin_install
-
-
-%files
-%license LICENSE
-%{_bindir}/%{name}
diff --git a/guidelines/modules/ROOT/examples/haskell-library-only.spec b/guidelines/modules/ROOT/examples/haskell-library-only.spec
deleted file mode 100644
index f8c3f7b..0000000
--- a/guidelines/modules/ROOT/examples/haskell-library-only.spec
+++ /dev/null
@@ -1,70 +0,0 @@
-%global pkg_name @PACKAGE@
-
-Name:           ghc-%{pkg_name}
-Version:        @VERSION@
-Release:        1%{?dist}
-Summary:        @SUMMARY@
-
-License:        @LICENSE@
-URL:            https://hackage.haskell.org/package/%{pkg_name}
-Source:         https://hackage.haskell.org/package/%{pkg_name}-%{version}/%{pkg_name}-%{version}.tar.gz
-
-BuildRequires:  ghc-Cabal-devel
-BuildRequires:  ghc-rpm-macros
-BuildRequires:  ghc-base-prof
-
-%description
-@DESCRIPTION@
-
-%package devel
-Summary:        Haskell %{pkg_name} library development files
-Provides:       %{name}-static = %{version}-%{release}
-Provides:       %{name}-static%{?_isa} = %{version}-%{release}
-Requires:       ghc-compiler = %{ghc_version}
-Requires:       %{name}%{?_isa} = %{version}-%{release}
-
-%description devel
-This package provides the Haskell %{pkg_name} library development files.
-
-
-%package doc
-Summary:        Haskell %{pkg_name} library documentation
-BuildArch:      noarch
-
-%description doc
-This package provides the Haskell %{pkg_name} library documentation.
-
-
-%package prof
-Summary:        Haskell %{pkg_name} profiling library
-Requires:       %{name}-devel%{?_isa} = %{version}-%{release}
-Supplements:    (%{name}-devel and ghc-prof)
-
-%description prof
-This package provides the Haskell %{pkg_name} profiling library.
-
-
-%prep
-%setup -q -n %{pkg_name}-%{version}
-
-
-%build
-%ghc_lib_build
-
-
-%install
-%ghc_lib_install
-
-
-%files -f %{name}.files
-%license LICENSE
-
-
-%files devel -f %{name}-devel.files
-
-
-%files doc -f %{name}-doc.files
-%license LICENSE
-
-
-%files prof -f %{name}-prof.files
diff --git a/guidelines/modules/ROOT/examples/ocaml-dune-example.spec b/guidelines/modules/ROOT/examples/ocaml-dune-example.spec
deleted file mode 100644
index 17c9cdf..0000000
--- a/guidelines/modules/ROOT/examples/ocaml-dune-example.spec
+++ /dev/null
@@ -1,67 +0,0 @@
-%ifnarch %{ocaml_native_compiler}
-%global debug_package %{nil}
-%endif
-
-Name:           ocaml-foolib
-Version:        1.2.3
-Release:        %autorelease
-Summary:        OCaml library for fooing bars
-
-License:        LGPL-2.1-or-later
-URL:            https://www.example.com/foolib
-Source:         https://www.example.com/foolib-%{version}.tar.gz
-
-BuildRequires:  ocaml
-BuildRequires:  ocaml-dune
-
-%description
-OCaml library for fooing bars.  This library can also foo bazes.
-
-
-%package        devel
-Summary:        Development files for %{name}
-Requires:       %{name}%{?_isa} = %{version}-%{release}
-
-
-%description    devel
-The %{name}-devel package contains libraries and signature files for
-developing applications that use %{name}.
-
-
-%prep
-%autosetup -n foolib-%{version}
-
-
-%build
-# Build all installable targets
-%dune_build
-# Build a specific set of targets
-%dune_build -p bazzer,boffer
-# Build non-default targets
-%dune_build @install @doc
-
-
-%install
-# Install all installable targets
-%dune_install
-# Install a specific set of targets
-%dune_install bazzer boffer
-
-
-%check
-# Check all installable targets
-%dune_check
-# Check a specific set of targets
-%dune_check -p bazzer,boffer
-
-
-%files -f .ofiles
-%doc README
-%license LICENSE
-
-
-%files devel -f .ofiles-devel
-
-
-%changelog
-%autochangelog
diff --git a/guidelines/modules/ROOT/examples/ocaml-example.spec b/guidelines/modules/ROOT/examples/ocaml-example.spec
deleted file mode 100644
index 5167b9f..0000000
--- a/guidelines/modules/ROOT/examples/ocaml-example.spec
+++ /dev/null
@@ -1,74 +0,0 @@
-%ifnarch %{ocaml_native_compiler}
-%global debug_package %{nil}
-%endif
-
-Name:           ocaml-foolib
-Version:        1.2.3
-Release:        %autorelease
-Summary:        OCaml library for fooing bars
-
-License:        LGPL-2.1-or-later
-URL:            https://www.example.com/foolib
-Source:         https://www.example.com/foolib-%{version}.tar.gz
-
-BuildRequires:  ocaml
-BuildRequires:  ocaml-findlib
-
-%description
-OCaml library for fooing bars.  This library can also foo bazes.
-
-
-%package        devel
-Summary:        Development files for %{name}
-Requires:       %{name}%{?_isa} = %{version}-%{release}
-
-
-%description    devel
-The %{name}-devel package contains libraries and signature files for
-developing applications that use %{name}.
-
-
-%prep
-%autosetup -n foolib-%{version}
-
-
-%build
-# You may need a ./configure step here.
-make byte
-%ifarch %{ocaml_native_compiler}
-make opt
-%endif
-
-
-%install
-# These rules work if the library uses 'ocamlfind install' to install itself.
-export OCAMLFIND_DESTDIR=%{buildroot}%{ocamldir}
-mkdir -p $OCAMLFIND_DESTDIR/stublibs
-%make_install
-
-
-%files
-%doc README
-%license LICENSE
-%{ocamldir}/foolib
-%ifarch %{ocaml_native_compiler}
-%exclude %{ocamldir}/foolib/*.a
-%exclude %{ocamldir}/foolib/*.cmxa
-%exclude %{ocamldir}/foolib/*.cmx
-%endif
-%exclude %{ocamldir}/foolib/*.mli
-%{ocamldir}/stublibs/*.so
-%{ocamldir}/stublibs/*.so.owner
-
-
-%files devel
-%ifarch %{ocaml_native_compiler}
-%{ocamldir}/foolib/*.a
-%{ocamldir}/foolib/*.cmxa
-%{ocamldir}/foolib/*.cmx
-%endif
-%{ocamldir}/foolib/*.mli
-
-
-%changelog
-%autochangelog
diff --git a/guidelines/modules/ROOT/examples/ocaml-topkg-example.spec b/guidelines/modules/ROOT/examples/ocaml-topkg-example.spec
deleted file mode 100644
index 4365de2..0000000
--- a/guidelines/modules/ROOT/examples/ocaml-topkg-example.spec
+++ /dev/null
@@ -1,72 +0,0 @@
-%ifnarch %{ocaml_native_compiler}
-%global debug_package %{nil}
-%endif
-
-Name:           ocaml-foolib
-Version:        1.2.3
-Release:        %autorelease
-Summary:        OCaml library for fooing bars
-
-License:        LGPL-2.1-or-later
-URL:            https://www.example.com/foolib
-Source:         https://www.example.com/foolib-%{version}.tar.gz
-
-BuildRequires:  ocaml
-BuildRequires:  ocaml-findlib
-BuildRequires:  ocaml-topkg-devel
-BuildRequires:  python3
-
-%description
-OCaml library for fooing bars.  This library can also foo bazes.
-
-
-%package        devel
-Summary:        Development files for %{name}
-Requires:       %{name}%{?_isa} = %{version}-%{release}
-
-
-%description    devel
-The %{name}-devel package contains libraries and signature files for
-developing applications that use %{name}.
-
-
-%prep
-%autosetup -n foolib-%{version}
-
-# Enable debuginfo if upstream does not
-echo true: debug >> _tags
-
-
-%build
-ocaml pkg/pkg.ml build --tests true
-
-
-%install
-mkdir -p %{buildroot}%{ocamldir}/foolib
-cp -p _build/{opam,pkg/META} %{buildroot}%{ocamldir}/foolib
-%ifarch %{ocaml_native_compiler}
-cp -a _build/src/*.{a,cma,cmi,cmt,cmti,cmx,cmxa,cmxs,mli} \
-  %{buildroot}%{ocamldir}/foolib
-%else
-cp -a _build/src/*.{cma,cmi,cmt,cmti,mli} %{buildroot}%{ocamldir}/foolib
-%endif
-
-# This macro requires python3 in the buildroot
-%ocaml_files
-
-
-%check
-ocaml pkg/pkg.ml test
-
-
-%files -f .ofiles
-%doc README
-%license LICENSE
-
-
-%files devel -f .ofiles-devel
-%ifarch %{ocaml_native_compiler}
-
-
-%changelog
-%autochangelog
diff --git a/guidelines/modules/ROOT/examples/python-example.spec b/guidelines/modules/ROOT/examples/python-example.spec
deleted file mode 100644
index 3ef7da9..0000000
--- a/guidelines/modules/ROOT/examples/python-example.spec
+++ /dev/null
@@ -1,45 +0,0 @@
-%global srcname example
-
-Name:           python-%{srcname}
-Version:        1.2.3
-Release:        1%{?dist}
-Summary:        Example python module
-
-License:        MIT
-URL:            https://pypi.python.org/pypi/example
-Source:         %{pypi_source}
-
-BuildArch:      noarch
-
-%global _description %{expand:
-A python module which provides a convenient example. This is the
-rest of the description that provides more details.}
-
-%description %_description
-
-%package -n python3-%{srcname}
-Summary:        %{summary}
-BuildRequires:  python3-devel
-BuildRequires:  python3-setuptools
-
-%description -n python3-%{srcname} %_description
-
-%prep
-%autosetup -n %{srcname}-%{version}
-
-%build
-%py3_build
-
-%install
-%py3_install
-
-%check
-%{python3} setup.py test
-
-# Note that there is no %%files section for the unversioned python module
-%files -n python3-%{srcname}
-%license COPYING
-%doc README.rst
-%{python3_sitelib}/%{srcname}-*.egg-info/
-%{python3_sitelib}/%{srcname}/
-%{_bindir}/sample-exec
diff --git a/guidelines/modules/ROOT/examples/spectemplate-forge-branch.spec b/guidelines/modules/ROOT/examples/spectemplate-forge-branch.spec
deleted file mode 100644
index 3986a30..0000000
--- a/guidelines/modules/ROOT/examples/spectemplate-forge-branch.spec
+++ /dev/null
@@ -1,49 +0,0 @@
-# This template shows how to package a branch state using the forgemeta macro.
-#
-# BRANCH STATES ARE NOT REPRODUCIBLE AND SHOULD NEVER BE SHARED WITH OTHERS.
-#
-# For more explanations on forgemeta, read the forgemeta-release template.
-#
-# The project url on the forge
-%global forgeurl 
-#
-# The branch being packaged
-%global branch   
-#
-#  – use the “-i” flag to display the variables forgemeta reads and sets
-#  – use the “-v” flag if you want verbose processing
-#  – remove  “-i” and “-v” before commit
-%forgemeta
-
-# The following lines use variables computed by forgemeta as default values.
-# You can replace them with manual definitions.
-# forgemeta will prepend branch information to dist. Release ordering is
-# controlled by the packager with x%{?dist}/0.x%{?dist} number chains.
-Name:    
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:	 %{forgeurl}
-Source:  %{forgesource}
-%description
-
-
-%prep
-#  – an autosetup wrapper, forgeautosetup, is also provided
-#  – use the “-v” flag if you want verbose processing; remove it before commit
-#  – call forgesetup/autosetup directly if you do not like the result
-%forgesetup
-#
-# After this point the archive extraction is done. forgemeta is no longer used.
-
-%build
-
-%install
-
-%check
-
-%files
-%license 
-%doc 
-
-%changelog
diff --git a/guidelines/modules/ROOT/examples/spectemplate-forge-commit.spec b/guidelines/modules/ROOT/examples/spectemplate-forge-commit.spec
deleted file mode 100644
index 0af8bb4..0000000
--- a/guidelines/modules/ROOT/examples/spectemplate-forge-commit.spec
+++ /dev/null
@@ -1,46 +0,0 @@
-# This template shows how to package a commit state using the forgemeta macro.
-# For more explanations on forgemeta, read the forgemeta-release template.
-#
-# The project url on the forge
-%global forgeurl 
-#
-# The commit being packaged (when using git, a full hash)
-%global commit   
-#
-#  – use the “-i” flag to display the variables forgemeta reads and sets
-#  – use the “-v” flag if you want verbose processing
-#  – remove  “-i” and “-v” before commit
-%forgemeta
-
-# The following lines use variables computed by forgemeta as default values.
-# You can replace them with manual definitions.
-# forgemeta will prepend commit information to dist. Release ordering is
-# controlled by the packager with x%{?dist}/0.x%{?dist} numbers chains.
-Name:    
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:	 %{forgeurl}
-Source:  %{forgesource}
-%description
-
-
-%prep
-#  – an autosetup wrapper, forgeautosetup, is also provided
-#  – use the “-v” flag if you want verbose processing; remove it before commit
-#  – call forgesetup/autosetup directly if you do not like the result
-%forgesetup
-#
-# After this point the archive extraction is done. forgemeta is no longer used.
-
-%build
-
-%install
-
-%check
-
-%files
-%license 
-%doc 
-
-%changelog
diff --git a/guidelines/modules/ROOT/examples/spectemplate-forge-multi.spec b/guidelines/modules/ROOT/examples/spectemplate-forge-multi.spec
deleted file mode 100644
index 3730473..0000000
--- a/guidelines/modules/ROOT/examples/spectemplate-forge-multi.spec
+++ /dev/null
@@ -1,81 +0,0 @@
-# This template shows how to package multiple source archives using the
-# forgemeta macro.
-#
-# PACKAGING MULTIPLE PROJECT ARCHIVES IN A SINGLE SPEC IS DISCOURAGED. IT OFTEN
-# REQUIRES ERROR-INDUCING VERSIONNING DECISIONS. In rpm, versioning is not an
-# administrative decoration. Versioning controls the upgrade logic. If upstream
-# deemed necessary to release a project through multiple archives, mirror its
-# decision using multiple spec files. That will be safer, simpler, and
-# ultimately less work.
-#
-# For more explanations on forgemeta, read the forgemeta-release template.
-#
-# Start by declaring the characteristics of each source using a	number-suffixed
-# variable block:
-#  – no suffix and zero suffix blocks are aliases
-#  – they are “special” and identify the main source archive
-#  — they use Version: to identify a release
-#  – other blocks use a version<number> variable for the same need
-#  – the syntax is otherwise identical to single archive mode; see the various
-#    forge templates for examples.
-#
-# Main archive. In this example we package a full release
-%global forgeurl0 
-Version:          
-
-# Second archive.
-%global forgeurl1 
-%global version1  
-
-# Third archive. This time a tag. Continue as necessary.
-%global forgeurl2 
-%global tag2      
-
-#  – use the “-a” flag to process all the source archives in a single pass
-#  – use     “-z <number>” to process only the declaration block suffixed with
-#    <number>
-#  — without “-a” of “-z <number>” only the main archive is processed
-#  – use the “-i” flag to display the variables forgemeta reads and sets
-#  – use the “-v” flag if you want verbose processing
-#  – remove  “-i” and “-v” before commit
-%forgemeta -a
-
-# The following lines use variables computed by forgemeta as default values.
-# You can replace them with manual definitions.
-# Release ordering is controlled by the packager with x%{?dist}/0.x%{?dist}
-# numbers chains.
-Name:    
-Release: 1%{?dist}
-Summary: 
-URL:	 %{forgeurl0}
-# https://github.com/rpm-software-management/rpm/issues/539
-Source0: %{forgesource0}
-Source1: %{forgesource1}
-Source2: %{forgesource2}
-%description
-
-
-%prep
-#  – use the “-a” flag to process all the source archives in a single pass
-#  – use     “-z <number>” to process only the declaration block suffixed with
-#    <number>
-#  — without “-a” of “-z <number>” only the main archive is processed
-#  – an autosetup wrapper, forgeautosetup, is also provided
-#  – forgeautosetup does not understand “-a”
-#  – use the “-v” flag if you want verbose processing; remove it before commit
-#  – call forgesetup/autosetup directly if you do not like the result
-%forgesetup -a
-#
-# After this point the archive extraction is done. forgemeta is no longer used.
-
-%build
-
-%install
-
-%check
-
-%files
-%license 
-%doc 
-
-%changelog
diff --git a/guidelines/modules/ROOT/examples/spectemplate-forge-release.spec b/guidelines/modules/ROOT/examples/spectemplate-forge-release.spec
deleted file mode 100644
index 7b7ec09..0000000
--- a/guidelines/modules/ROOT/examples/spectemplate-forge-release.spec
+++ /dev/null
@@ -1,58 +0,0 @@
-# This template shows how to package a commit state using the forgemeta macro.
-# That should be the default target use case.
-# Other less common use cases are documented in separate templates.
-#
-# The project url on the forge, for example
-# https://gitlab.gnome.org/GNOME/gtk/
-%global forgeurl 
-#
-# Packaging a release requires setting Version before calling forgemeta.
-# Because most forges follow the git model, and git made no provision for
-# release objects, forgemeta will try to guess the customary way to write
-# release tags on the selected forge.
-# If it guesses wrong use the forge-tag template instead of this one.
-Version:         
-#
-# forgemeta converts the suppplied rpm variables to variables that can be used
-# in the spec file. Most of those can be overriden before or after the
-# forgemeta call.
-#  – use the “-i” flag to display the variables forgemeta reads and sets
-#  – use the “-v” flag if you want verbose processing
-#  – remove  “-i” and “-v” before commit
-%forgemeta
-
-# The following lines use  variables computed by forgemeta as default values.
-# You can replace them with manual definitions. For example, replace forgeurl
-# with the project homepage if it exists separately from the repository URL.
-# Only replace the variables when it adds value to the spec file and you
-# understand the consequences. Release ordering is controlled by the packager
-# with x%{?dist}/0.x%{?dist} number chains.
-Name:    
-Release: 1%{?dist}
-Summary: 
-URL:	 %{forgeurl}
-Source:  %{forgesource}
-%description
-
-
-%prep
-# forgesetup calls setup with the correct flags for archives downloaded from
-# the selected forge. A forgeautosetup autosetup wrapper is also provided. If
-# you disagree with the computed setup/autosetup flags, just call
-# setup/autosetup directly.
-#  – use the “-v” flag if you want verbose processing
-%forgesetup
-#
-# After this point the archive extraction is done. forgemeta is no longer used.
-
-%build
-
-%install
-
-%check
-
-%files
-%license 
-%doc 
-
-%changelog
diff --git a/guidelines/modules/ROOT/examples/spectemplate-forge-tag.spec b/guidelines/modules/ROOT/examples/spectemplate-forge-tag.spec
deleted file mode 100644
index bf0035b..0000000
--- a/guidelines/modules/ROOT/examples/spectemplate-forge-tag.spec
+++ /dev/null
@@ -1,46 +0,0 @@
-# This template shows how to package a tag state using the forgemeta macro.
-# For more explanations on forgemeta, read the forgemeta-release template.
-#
-# The project url on the forge
-%global forgeurl 
-#
-# The tag being packaged
-%global tag      
-#
-#  – use the “-i” flag to display the variables forgemeta reads and sets
-#  – use the “-v” flag if you want verbose processing
-#  – remove  “-i” and “-v” before commit
-%forgemeta
-
-# The following lines use variables computed by forgemeta as default values.
-# You can replace them with manual definitions.
-# forgemeta will prepend tag information to dist. Release ordering is
-# controlled by the packager with x%{?dist}/0.x%{?dist} numbers chains.
-Name:    
-Version: 
-Release: 1%{?dist}
-Summary: 
-URL:	 %{forgeurl}
-Source:  %{forgesource}
-%description
-
-
-%prep
-#  – an autosetup wrapper, forgeautosetup, is also provided
-#  – use the “-v” flag if you want verbose processing; remove it before commit
-#  – call forgesetup/autosetup directly if you do not like the result
-%forgesetup
-#
-# After this point the archive extraction is done. forgemeta is no longer used.
-
-%build
-
-%install
-
-%check
-
-%files
-%license 
-%doc 
-
-%changelog
diff --git a/guidelines/modules/ROOT/nav.adoc b/guidelines/modules/ROOT/nav.adoc
deleted file mode 100644
index 7c0c68a..0000000
--- a/guidelines/modules/ROOT/nav.adoc
+++ /dev/null
@@ -1,86 +0,0 @@
-* https://fedoraproject.org/wiki/EPEL:Packaging[EPEL-specific guidelines]
-
-* xref:Alternatives.adoc[Alternatives]
-* xref:AppData.adoc[AppData]
-* xref:AutoProvidesAndRequiresFiltering.adoc[Dependency Filtering]
-* xref:Conflicts.adoc[Conflicts]
-* xref:CryptoPolicies.adoc[Crypto Policies]
-* xref:Debuginfo.adoc[Debuginfo]
-* xref:DefaultServices.adoc[Default Services]
-* xref:vpath.adoc[Defining source and build directories]
-* xref:deprecating-packages.adoc[Deprecating Packages]
-* xref:Directory_Replacement.adoc[Directory Replacement]
-* xref:DistTag.adoc[Dist Tag]
-* xref:Initial_Service_Setup.adoc[Initial Service Setup]
-* xref:KDEPackaging.adoc[KDE Packaging Guidelines]
-* xref:Langpacks.adoc[Language Packs]
-* xref:LicensingGuidelines.adoc[Licensing]
-* xref:manual-changelog.adoc[Manual Changelog]
-* xref:Naming.adoc[Naming]
-* xref:PatchUpstreamStatus.adoc[Patch Status]
-* xref:Per-Product_Configuration.adoc[Per-Product Configuration]
-* xref:PkgConfigBuildRequires.adoc[Pkgconfig Build Dependencies]
-* xref:Pkcs11Support.adoc[PKCS#11 / Smartcard Support Guidelines]
-* xref:ReviewGuidelines.adoc[Review Guidelines]
-* xref:RPMMacros.adoc[RPM Macros]
-* xref:RPM_Source_Dir.adoc[RPM Source Dir]
-* xref:Scriptlets.adoc[Scriptlets]
-* xref:SourceURL.adoc[SourceURL]
-* xref:SSLCertificateHandling.adoc[SSL Certificate Handling]
-* xref:Systemd.adoc[Systemd]
-* xref:Tmpfiles.d.adoc[Tmpfiles.d]
-* xref:UnownedDirectories.adoc[Unowned Directories]
-* xref:UsersAndGroups.adoc[Users and Groups]
-* xref:Versioning.adoc[Versioning]
-* xref:WeakDependencies.adoc[Weak Dependencies]
-* xref:what-can-be-packaged.adoc[What Can Be Packaged]
-
-* Build Systems
-** xref:CMake.adoc[CMake]
-** xref:Meson.adoc[Meson]
-
-* Programming Languages
-** xref:Ada.adoc[Ada]
-** xref:C_and_C++.adoc[C and {cpp}]
-** xref:D.adoc[D]
-** xref:Fortran.adoc[Fortran]
-** xref:Golang.adoc[Golang]
-*** xref:Golang_old.adoc[Legacy guidelines]
-**** xref:Golang_advanced.adoc[Advanced uses cases]
-**** xref:Golang_templates.adoc[Additional annotated templates]
-** xref:Haskell.adoc[Haskell]
-** xref:Java.adoc[Java]
-*** xref:java-packaging-howto::index.adoc[Java Packaging HOWTO]
-** xref:JavaScript.adoc[JavaScript]
-** xref:Lisp.adoc[Lisp]
-** xref:Lua.adoc[Lua]
-** xref:Mono.adoc[Mono]
-** xref:Node.js.adoc[Node.js]
-** xref:OCaml.adoc[OCaml]
-** xref:Octave.adoc[Octave]
-** xref:Perl.adoc[Perl]
-** xref:PHP.adoc[PHP]
-** xref:Python.adoc[Python]
-*** xref:Python_201x.adoc[Python (201x-era)]
-*** xref:Python_Appendix.adoc[Python Appendix]
-** xref:R.adoc[R]
-** xref:Ruby.adoc[Ruby]
-** xref:Rust.adoc[Rust]
-** xref:Tcl.adoc[Tcl/Tk extensions]
-
-* Other Domain-specific Guidelines
-** xref:Ansible_collections.adoc[Ansible Collections]
-** xref:BLAS_LAPACK.adoc[BLAS/LAPACK]
-** xref:CronFiles.adoc[CronFiles]
-** xref:Emacs.adoc[Emacs]
-** xref:EnvironmentModules.adoc[EnvironmentModules]
-** xref:FontsPolicy.adoc[Fonts]
-** xref:GAP.adoc[GAP]
-** xref:LibreOfficeExtensions.adoc[LibreOffice Extensions]
-** xref:MinGW.adoc[MinGW]
-** xref:MPI.adoc[MPI]
-** xref:ShellCompletions.adoc[Shell Completions]
-** xref:SugarActivityGuidelines.adoc[Sugar activities]
-** xref:Tree-sitter.adoc[Tree-sitter parsers]
-** xref:Web_Assets.adoc[Web Assets]
-** xref:WordPress_plugin_packaging_guidelines.adoc[WordPress extensions]
diff --git a/guidelines/modules/ROOT/pages/Ada.adoc b/guidelines/modules/ROOT/pages/Ada.adoc
deleted file mode 100644
index a8959f8..0000000
--- a/guidelines/modules/ROOT/pages/Ada.adoc
+++ /dev/null
@@ -1,209 +0,0 @@
-= Ada Packaging Guidelines
-
-:last-reviewed: 2019-04-04
-
-This document describes the current policies for packaging
-Ada programs and libraries for Fedora.
-These are Ada-specific amendments to the generic Packaging Guidelines.
-Ada packages must also conform to the link:../[Packaging Guidelines]
-and the link:../ReviewGuidelines/[Review Guidelines].
-
-== Compilation
-
-* Ada code in Fedora *MUST* be compiled using GNAT,
-  the default Ada compiler in Fedora.
-  All packages that contain Ada code *MUST* have “`+BuildRequires: gcc-gnat+`”
-  to ensure that the compiler is available.
-* The GNAT tools are usually invoked through the builder GPRbuild,
-  so Ada packages typically need “`+BuildRequires: gprbuild+`”.
-* There are a number of RPM macros that contain
-  Fedora’s standard compiler and linker flags adapted for GNAT.
-  The appropriate macro *MUST* be used in the build stage.
-  The right macro to use depends on what build tools the package uses.
-** For packages that are built with GPRbuild or Gnatmake but without Comfignat
-   there are the macros
-   +++<var>GPRbuild_flags</var>+++
-   and +++<var>Gnatmake_flags</var>+++,
-   which contain builder, compiler and linker flags.
-** In case a package’s build system invokes the underlying GNAT tools
-   without using GPRbuild or Gnatmake,
-   then the appropriate macro for each tool *MUST* be used.
-   If for example Gnatlink is invoked directly,
-   then the expansion of +++<var>Gnatlink_flags</var>+++ shall be passed to it.
-** For packages whose build systems use Comfignat
-   there is the macro +++<var>Comfignat_make</var>+++.
-   It expands to a Make command with appropriate values
-   for Comfignat’s configuration variables,
-   including builder, compiler and linker flags,
-   directory variables and the directories project.
-   Use it alone to build the default target:
-+
-....
-%build
-%{Comfignat_make}
-....
-+
-If needed, a different target and/or additional variables may be appended:
-+
-....
-%{Comfignat_make} demo_programs atomic_doodads=true
-....
-+
-For the installation stage of Comfignat-using packages,
-the macro +++<var>make_install</var>+++ (*not* +++<var>makeinstall</var>+++)
-is recommended.
-* The macros +++<var>GPRbuild_arches</var>+++ and +++<var>GNAT_arches</var>+++
-expand to a list of architectures
-where GNAT packages are available in Fedora.
-When there is a need to prevent attempts
-to build an Ada package on secondary architectures
-where GNAT has not been bootstrapped,
-this *MUST* be done with either “`+ExclusiveArch: %{GPRbuild_arches}+`”
-or “`+ExclusiveArch: %{GNAT_arches}+`”.
-* All packages that contain Ada code *MUST* have
-“`+BuildRequires: fedora-gnat-project-common+`”
-to ensure that the necessary RPM macros are defined.
-* If the upstream source package comes with a build system,
-for example a GNAT project file or makefiles and a configuration script,
-then it’s probably best to use that if possible.
-If not, it is recommended that the packager write a GNAT project file
-and use GPRbuild to control the compilation.
-
-=== Trampolines
-
-An executable stack has been made a linker error in Fedora.
-This can affect Ada packages because
-https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html[GCC uses trampolines]
-to implement some language constructs.
-The compiler’s usage of trampolines has been greatly reduced, but
-https://gcc.gnu.org/onlinedocs/gnat_rm/No_005fImplicit_005fDynamic_005fCode.html[some cases remain].
-One case that occurs is
-when a nested subprogram in Ada
-is passed as a callback routine
-to a function written in C –
-which means that the executable stack is also exposed to C code
-that may contain buffer overflows.
-In such cases the options are
-to explicitly allow an executable stack
-by passing “`+-largs -Wl,--no-warn-execstack+`” to GPRbuild,
-or restructure the code to eliminate the need for trampolines.
-Which option is best may depend on
-how exposed the program is to potentially hostile input.
-
-Correct usage of the RPM macros
-should result in a warning message from the compiler
-that points out where in the code a trampoline is needed.
-
-== Runpaths
-
-GPRbuild adds a runpath to the built binaries by default.
-Fedora’s builder flags normally include an option
-to disable the automatic runpath.
-There are however cases where it would be advantageous to allow a runpath.
-Libraries can have test suites or auxiliary programs that aren’t installed
-but run during the build and need to link to the library in the build directory,
-and they may rely on an automatic runpath for this.
-In those cases the spec file may define a macro named
-+++<var>GNAT_add_rpath</var>+++.
-The builder will then be allowed to add a runpath
-in those parts of the spec file where
-+++<var>GNAT_add_rpath</var>+++ is defined.
-
-NOTE: +++<var>GNAT_add_rpath</var>+++ does not exempt a package
-from the Packaging Guidelines.
-link:../#_beware_of_rpath[The policy on runpaths] still applies.
-
-== Devel packages
-
-* Ada library packages *MUST* have a -devel subpackage
-containing all the files that are necessary for compilation of code
-that uses the library.
-This includes +Ada specification files (*.ads),
-Ada body files (*.adb),
-Ada library information files (*.ali)
-and GNAT project files (*.gpr).+
-(There is no requirement to include all body files.
-Typically only some body files are needed.)
-
-* The -devel package *MUST NOT* contain any makefiles
-or other files that are only used for recompiling the library.
-
-* The -devel package *MUST NOT* contain any +*.o+ files.
-
-=== GNAT project files
-
-* The -devel package *MUST* contain one or more GNAT project files
-to be imported by other projects that use the library.
-
-* Project files *MUST* be architecture-independent.
-This means that the same project file must point to libraries in
-/usr/lib or /usr/lib64
-depending on what target architecture the compiler is currently compiling for.
-This *SHOULD* be done by importing the “directories” project
-(that is, the project file directories.gpr)
-and using the variable
-+++<var>Directories.Libdir</var>+++
-which is defined there.
-The value of
-+++<var>Directories.Libdir</var>+++
-is set to either “/usr/lib” or “/usr/lib64” depending on the hardware platform.
-
-* Project files *MUST NOT* contain hard-coded directory names,
-neither absolute nor relative; they should get them from some source.
-The source may be an Autoconf-generated configuration script
-or other build system.
-Project files that aren’t pre-processed by such a build system
-*SHOULD* use the variable
-+++<var>Directories.Includedir</var>+++
-rather than a hard-coded “/usr/include”.
-
-* If the “directories” project is used,
-then the -devel package *MUST* have an explicit
-“`+Requires: fedora-gnat-project-common+`”.
-
-* Project files *MUST* have an
-+++<var>Externally_Built</var>+++
-attribute equal to “true”.
-
-Here’s an example of what a project file installed with a library may look like:
-
-....
-with "directories";
-project Example is
-   for Library_Name use "example";
-   for Source_Dirs use (Directories.Includedir & "/example");
-   for Library_Dir use Directories.Libdir;
-   for Library_ALI_Dir use Directories.Libdir & "/example";
-   for Externally_Built use "true";
-end Example;
-....
-
-== File placement
-
-* Ada source files in -devel packages (+*.ads and *.adb+)
-*MUST* be placed in the `+%{_includedir}+` directory
-or a subdirectory thereof.
-Placing them directly in `+%{_includedir}+` may be appropriate
-if there are very few of them in the package
-and their names include the name of the library.
-Otherwise they should usually be placed in a subdirectory,
-for example `+%{_includedir}/%{name}+`.
-
-* Ada library information files (+*.ali+)
-*MUST* be placed in a subdirectory of `+%{_libdir}+`,
-for example `+%{_libdir}/%{name}+`.
-
-* GNAT projects files (+*.gpr+)
-*MUST* be placed in the `+%{_GNAT_project_dir}+` directory
-or a subdirectory thereof.
-A subdirectory, for example `+%{_GNAT_project_dir}/%{name}+`,
-may be a good idea if there are lots of project files in the same package
-or if they have generic names.
-Otherwise they should usually be placed directly in `+%{_GNAT_project_dir}+`.
-The name of the library *MUST* be included
-either in the name of each project file
-or in the name of the subdirectory where the project files are placed.
-
-Packages that use GPRinstall in the installation phase
-can use the macro +++<var>GPRinstall_flags</var>+++
-to pass the correct pathnames and other parameters to GPRinstall.
diff --git a/guidelines/modules/ROOT/pages/Alternatives.adoc b/guidelines/modules/ROOT/pages/Alternatives.adoc
deleted file mode 100644
index 31a3a87..0000000
--- a/guidelines/modules/ROOT/pages/Alternatives.adoc
+++ /dev/null
@@ -1,190 +0,0 @@
-= Alternatives
-
-:last-reviewed: 2019-04-04
-
-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+`
-For more information, see `+update-alternatives(8)+` manpage.
-
-== Usage within Fedora
-
-Alternatives *MAY* be used to allow parallel installation of software when:
-
-* the software can be used as a drop-in replacement
-and functions with sufficient similarity
-that users and other programs would, within reason,
-not need to know which variant is currently installed
-
-*AND*
-
-* the selection of the software is only performed system-wide
-by the system administrator
-and end users do not have a need to switch between the variants.
-
-Inversely, alternatives *MUST NOT* be used when:
-
-* The software is not a drop-in replacement.
-For instance, if common command line arguments are different
-between the two variants,
-alternatives *MUST NOT* be used.
-
-*OR*
-
-* End users will care which variant they are using.
-If a non-root user would gain value by switching between the variants
-then alternatives *MUST NOT* be used.
-
-A good example of using alternatives are the various MTAs
-which all provide `+/usr/bin/sendmail+` with similar command line arguments.
-
-Bad examples of using alternatives include:
-
-* the various MPI environments where users care
-both about which MPI environment they compile against
-and which one they run against
-
-* choice of editor when the user invokes "vi"
-where the user will care about feature availability,
-compatibility with plugins, etc
-
-Cases where parallel installation is desirable but alternatives is unsuitable
-may be scenarios where
-link:../EnvironmentModules/[Environment Modules]
-are appropriate.
-MPI and python-sphinx (until Fedora 31)
-are example packages using environment-modules for this purpose.
-
-== How to use alternatives
-
-If a package is using alternatives,
-the files which would otherwise conflict MUST be installed
-with an appropriate suffix
-(for example: `+%{_bindir}/sendmail.postfix+`
-instead of `+%{_bindir}/sendmail+`),
-the original locations MUST be touched
-(for example: `+touch %{_bindir}/sendmail+`),
-the links set up by alternatives MUST be listed as %ghost in the file list
-and proper Requires: MUST be added, like in the examples below.
-
-Putting the alternativized files in the file list
-ensures that they are owned by respective packages,
-which means that commands like:
-
-* rpm -qf /usr/bin/foo
-* dnf install /usr/bin/foo
-* repoquery --whatprovides /usr/bin/foo
-
-all work properly.
-Using %ghost for this purpose allows using globs and generated file lists.
-
-== Examples
-
-Example from antlr.spec:
-
-[source, rpm-spec]
-----
-Requires(post): %{_bindir}/update-alternatives
-Requires(postun): %{_bindir}/update-alternatives
-...
-%install
-...
-touch %{buildroot}%{_bindir}/antlr
-
-%post
-update-alternatives --install %{_bindir}/antlr \
-  %{name} %{_bindir}/antlr-java 10
-
-%postun
-if [ $1 -eq 0 ] ; then
-  update-alternatives --remove %{name} %{_bindir}/antlr-java
-fi
-...
-%files
-...
-%ghost %{_bindir}/antlr
-%{_bindir}/antlr-java
-----
-
-And a more complex example of alternatives invocation from sendmail.spec,
-slightly edited:
-
-[source, rpm-spec]
-----
-Requires(post): %{_bindir}/update-alternatives
-Requires(postun): %{_bindir}/update-alternatives
-Requires(preun): %{_bindir}/update-alternatives
-...
-%install
-...
-# rename files for alternative usage
-mv %{buildroot}%{_bindir}/sendmail %{buildroot}%{_bindir}/sendmail.sendmail
-touch %{buildroot}%{_bindir}/sendmail
-for i in mailq newaliases rmail; do
-    mv %{buildroot}%{_bindir}/$i %{buildroot}%{_bindir}/$i.sendmail
-    touch %{buildroot}%{_bindir}/$i
-done
-mv %{buildroot}%{_mandir}/man1/mailq.1 %{buildroot}%{_mandir}/man1/mailq.sendmail.1
-touch %{buildroot}%{_mandir}/man1/mailq.1
-mv %{buildroot}%{_mandir}/man1/newaliases.1 %{buildroot}%{_mandir}/man1/newaliases.sendmail.1
-touch %{buildroot}%{_mandir}/man1/newaliases.1
-mv %{buildroot}%{_mandir}/man5/aliases.5 %{buildroot}%{_mandir}/man5/aliases.sendmail.5
-touch %{buildroot}%{_mandir}/man5/aliases.5
-mv %{buildroot}%{_mandir}/man8/sendmail.8 %{buildroot}%{_mandir}/man8/sendmail.sendmail.8
-touch %{buildroot}%{_mandir}/man8/sendmail.8
-
-%postun
-if [ "$1" -ge "1" ]; then
-    if [ "`readlink %{_sysconfdir}/alternatives/mta`" == "%{_bindir}/sendmail.sendmail" ]; then
-        %{_bindir}/alternatives --set mta %{_bindir}/sendmail.sendmail
-    fi
-fi
-
-%post
-# Set up the alternatives files for MTAs.
-update-alternatives --install %{_bindir}/sendmail mta %{_bindir}/sendmail.sendmail 90 \
-    --slave %{_bindir}/mailq mta-mailq %{_bindir}/mailq.sendmail \
-    --slave %{_bindir}/newaliases mta-newaliases %{_bindir}/newaliases.sendmail \
-    --slave %{_bindir}/rmail mta-rmail %{_bindir}/rmail.sendmail \
-    --slave /usr/lib/sendmail mta-sendmail /usr/lib/sendmail.sendmail \
-    --slave %{_sysconfdir}/pam.d/smtp mta-pam %{_sysconfdir}/pam.d/smtp.sendmail \
-    --slave %{_mandir}/man8/sendmail.8.gz mta-sendmailman %{_mandir}/man8/sendmail.sendmail.8.gz \
-    --slave %{_mandir}/man1/mailq.1.gz mta-mailqman %{_mandir}/man1/mailq.sendmail.1.gz \
-    --slave %{_mandir}/man1/newaliases.1.gz mta-newaliasesman %{_mandir}/man1/newaliases.sendmail.1.gz \
-    --slave %{_mandir}/man5/aliases.5.gz mta-aliasesman %{_mandir}/man5/aliases.sendmail.5.gz \
-    --initscript sendmail
-...
-
-%preun
-if [ $1 = 0 ]; then
-    update-alternatives --remove mta %{_bindir}/sendmail.sendmail
-fi
-...
-
-%files
-...
-%ghost %{_bindir}/sendmail
-%ghost %{_bindir}/mailq
-%ghost %{_bindir}/newaliases
-%ghost %{_bindir}/rmail
-%ghost /usr/lib/sendmail
-%ghost %{_sysconfdir}/pam.d/smtp
-%ghost %{_mandir}/man8/sendmail.8.gz
-%ghost %{_mandir}/man1/mailq.1.gz
-%ghost %{_mandir}/man1/newaliases.1.gz
-%ghost %{_mandir}/man5/aliases.5.gz
-
-%{_bindir}/sendmail.sendmail
-%{_bindir}/mailq.sendmail
-%{_bindir}/newaliases.sendmail
-%{_bindir}/rmail.sendmail
-/usr/lib/sendmail.sendmail
-%config(noreplace) %{_sysconfdir}/pam.d/smtp.sendmail
-%{_mandir}/man8/sendmail.sendmail.8.gz
-%{_mandir}/man1/mailq.sendmail.1.gz
-%{_mandir}/man1/newaliases.sendmail.1.gz
-%{_mandir}/man5/aliases.sendmail.5.gz
-
-%attr(0755,root,root) %{_initrddir}/sendmail
-----
diff --git a/guidelines/modules/ROOT/pages/Ansible_collections.adoc b/guidelines/modules/ROOT/pages/Ansible_collections.adoc
deleted file mode 100644
index 00d1238..0000000
--- a/guidelines/modules/ROOT/pages/Ansible_collections.adoc
+++ /dev/null
@@ -1,441 +0,0 @@
-= Ansible Collection Packaging Guidelines
-:last-reviewed: 2022-09-25
-
-== Forward
-
-Ansible collections are packaged units of Ansible content,
-including modules and other types of plugins.
-Most Ansible Plugins are written in Python or Powershell.
-
-Some collections are also included in Ansible Community's `+ansible+`
-collection bundle, which is packaged in Fedora.
-All collections, whether or not they are included in the `+ansible+` package,
-MAY be packaged in Fedora.
-
-`+ansible+` depends on `+ansible-core+`, which contains the core engine and
-CLI programs (e.g. `+ansible+`, `+ansible-playbook+`).
-The `+ansible+` package has a different release cycle than individual collections,
-and it may contain older versions of the individual components.
-`+ansible+` installs collections in a different namespace and is parallel
-installable with individual collections.
-The Ansible engine searches for collections in the standalone collections
-directory first.
-
-See https://fedoraproject.org/wiki/Changes/Ansible5[Changes/Ansible5]
-for more information about the split between `+ansible+` and `+ansible-core+`.
-
-== Naming
-
-Collection packages MUST be named `+ansible-collection-NAMESPACE-NAME+`.
-For example, the `+community.general+` collection package is named
-`+ansible-collection-community-general+`.
-
-
-== Collection Source
-
-Collection source code MUST be downloaded from the collection's respective
-Git forge/other SCM repository.
-While the tarballs published to Ansible Galaxy contain all of the
-collection's Python/Powershell source code as well as some development files,
-they do not include the `+galaxy.yml+` build configuration
-and development files (e.g. unit tests) that the author may choose to remove.
-Note that the Ansible Community collection requirements mandate that
-collections tag releases in a public SCM repository.
-
-Collection packages SHOULD use `+%{ansible_collection_url NAMESPACE NAME}+`
-as the package's `+URL:+`.
-This points to the collection's homepage on Ansible Galaxy.
-
-
-== Dependencies
-
-=== Buildtime
-
-Collections MUST have `+BuildRequires: ansible-packaging+`.
-`+ansible-packaging+` provides macros and a dependency generator for packaging
-Ansible Collections.
-It also pulls in `+ansible-core+`,
-so `+BuildRequires: ansible-core+` SHOULD NOT be added manually.
-
-=== Runtime
-
-The dependency generator will generate the appropriate dependency on the Ansible engine.
-This ensures compatibility with Fedora 35
-which contains the classic `+ansible+` 2.9 package (instead of the collections bundle)
-and `+ansible-core+`. Both versions of the Ansible engine support collections,
-but they are not parallel installable.
-Packages MUST NOT manually `+Require+` `+ansible-core+` or `+ansible+`,
-unless they are known to require a specific version,
-in which case the appropriate version constraints should be used.
-
-The dependency generator also handles inter-collection dependencies.
-
-==== External dependencies of plugins
-
-Ansible collections may contain various plugins that have
-various external dependencies.
-The Ansible dev guide
-https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_best_practices.html#importing-and-using-shared-code[mandates]
-that plugins fail cleanly if these dependencies are not installed.
-Many times, external dependencies are only needed for a small subset of the
-collection which may or may not be widely used.
-Therefore, collection packages SHOULD weakly depend on these external libraries,
-i.e. use Recommends instead of Requires.
-
-Module dependencies are only needed on the target node not the controller node.
-Therefore, collection packages SHOULD NOT depend on these dependencies at all,
-weakly or strongly.
-Users are responsible for installing these dependencies on the target host.
-Modules that are intended to be used with `+delegate_to: localhost+` are an
-exception to this rule.
-
-The situation is a bit different for controller plugins, such as
-filter plugins, lookup plugins, connection plugins, or inventory plugins.
-Collections MAY add `+Recommends+` for dependencies of controller plugins.
-However, packagers should use discretion when adding any type of dependency
-and only do so when it is required for
-the central functionality of the collection.
-For instance, it makes sense for `+ansible-collection-community-docker+`
-to Recommend `+python3-docker+`,
-but it doesn't make sense for the larger, more general
-ansible-collection-community-general collection to Recommend `+python3-redis+`
-for the `+redis+` lookup plugin.
-This guideline seeks to prevent ballooning collection packages.
-`+ansible-core+` and `+ansible+` follow this same principle.
-
-
-== Build and Installation
-
-To build the collection artifact,
-packages MUST use `+%ansible_collection_build+` in `+%build+`.
-`+%ansible_collection_install+` MUST be used in `+%install+` to install the
-artifact.
-
-Packagers SHOULD use `+%files -f %{ansible_collection_filelist}+` to install
-the collection.
-The `+%{ansible_collection_filelist}+` is populated by `+%ansible_collection_install+`.
-
-== Unit Tests
-
-As per xref:index.adoc#_test_suites[the general Fedora Packaging Guidelines],
-collection packages SHOULD run upstream unit tests in `+%check+` if practical.
-Integration tests are impossible to run in the RPM build environment.
-In order to run unit tests, collections MUST `+BuildRequire+`
-`+ansible-packaging-tests+`, which pulls in the necessary dependencies.
-Some collections have other testing dependencies,
-which are usually specified in `+tests/unit/requirements.txt+`.
-These have to be added manually.
-The `+%ansible_test_unit+` macro MUST be used to run tests.
-
-[NOTE]
-.EPEL Compatibility
-====
-It is currently impossible to run unit tests on EPEL 8 and 9.
-
-ansible-core in RHEL 8 and 9 are built against alternative python stacks for
-which the necessary test dependencies are not available.
-
-The rest of these guidelines are applicable to EPEL 8 and 9,
-and `+ansible-packaging+` itself is available there.
-====
-
-== Unnecessary Files
-
-By default, collections ship with all of the files in the repository root,
-unless they are manually excluded.
-Therefore, many collections contain development files that are unwanted by users.
-
-Packagers SHOULD exclude these files, which SHOULD be done by patching the
-collection's `+galaxy.yml+` to add these files to the `+build_ignore+`
-configuration.
-These files SHOULD NOT be removed with `+rm+`.
-See the https://docs.ansible.com/ansible/latest/dev_guide/collections_galaxy_meta.html#collection-galaxy-metadata-structure[Ansible documentation]
-for more information on the `+galaxy.yml+` syntax.
-
-Common development files include:
-
-* The `+tests+` directory containing unit and integration tests
-* SCM configuration such as `+.gitignore+` and `+.keep+` files
-* The `+.azure-pipelines+` and `+.github+` directories that contain CI configuration
-
-These files often have to be removed downstream, as there are some unresolved
-issues with pushing these changes to upstream community collections. These
-issues are irrelevant in the Fedora context.
-
-== Shebangs
-
-Ansible plugins are not executable. However, many of them have `+#!/usr/bin/python+`
-shebangs for legacy reasons.
-These shebangs MUST be removed for the following reasons:
-
-1. Non-executable files shouldn't have shebangs
-2. Keeping the shebangs results in an unnecessary dependency
-on `+python-unversioned-command+`.
-
-`+%py3_shebang_fix+` MUST NOT be used, as it will break compatibility
-with certain Ansible target nodes.
-It won't fix the non-executable file issue, either.
-
-Shebangs can be removed with:
-
-[source,bash]
-----
-find -type f ! -executable -name '*.py' -print -exec sed -i -e '1{\@^#!.*@d}' '{}' +
-----
-
-
-== Documentation and License Files
-
-License files and documentation for collections are installed to the
-collection's directory in `+/usr/share/ansible+`, by default.
-Packagers MAY choose to either
-mark the license and documentation files in this directory with `+%license+`
-and `+%doc+`
-or to add the correct paths to `+build_ignore+` in `+galaxy.yml+` and
-install them into the standard directories.
-Avoid duplicating these files in both places.
-
-Note that some multi-licensed collections store licenses in a `+LICENSES+`
-directory. This whole directory MUST be marked with `+%license+`.
-
-Refer to the xref:legal::index.adoc[Legal docs] for the rules about
-allowed licenses and determining the `+License:+` field.
-
-
-== Example Specfile
-
-[source,rpm-spec]
-----
-# Only run tests where the dependencies are available
-%if %{defined fedora}
-%bcond_without tests
-%else
-%bcond_with tests
-%endif
-
-Name:           ansible-collection-community-rabbitmq
-Version:        1.2.2
-Release:        1%{?dist}
-Summary:        RabbitMQ collection for Ansible
-
-# plugins/module_utils/_version.py: Python Software Foundation License version 2
-License:        GPL-3.0-or-later and PSF-2.0
-URL:            %{ansible_collection_url community rabbitmq}
-%global forgeurl https://github.com/ansible-collections/community.rabbitmq
-Source0:        %{forgeurl}/archive/%{version}/%{name}-%{version}.tar.gz
-# Patch galaxy.yml to exclude unnecessary files from the built collection.
-# This is a downstream only patch.
-Patch0:         build_ignore.patch
-
-BuildRequires:  ansible-packaging
-%if %{with tests}
-BuildRequires:  ansible-packaging-tests
-# Collection specific test dependency
-BuildRequires:  glibc-all-langpacks
-%endif
-
-BuildArch:      noarch
-
-%description
-%{summary}.
-
-
-%prep
-%autosetup -n community.rabbitmq-%{version} -p1
-find -type f ! -executable -name '*.py' -print -exec sed -i -e '1{\@^#!.*@d}' '{}' +
-
-
-%build
-%ansible_collection_build
-
-
-%install
-%ansible_collection_install
-
-
-%if %{with tests}
-%check
-%ansible_test_unit
-%endif
-
-
-%files -f %{ansible_collection_filelist}
-%license COPYING PSF-license.txt
-%doc README.md CHANGELOG.rst
-
-%changelog
-----
-
-build_ignore.patch:
-
-[source, patch]
-----
-diff --git a/galaxy.yml b/galaxy.yml
-index 0b37162..acd029a 100644
---- a/galaxy.yml
-+++ b/galaxy.yml
-@@ -13,3 +13,13 @@ repository: https://github.com/ansible-collections/community.rabbitmq
- documentation: https://docs.ansible.com/ansible/latest/collections/community/rabbitmq/
- homepage: https://github.com/ansible-collections/community.rabbitmq
- issues: https://github.com/ansible-collections/community.rabbitmq/issues
-+build_ignore:
-+  # Remove unnecessary development files from the built package.
-+  - tests
-+  - .azure-pipelines
-+  - .gitignore
-+  # Licenses and docs are installed with %%doc and %%license
-+  - PSF-license.txt
-+  - COPYING
-+  - README.md
-+  - CHANGELOG.rst
-----
-
-
-== Macro Breakdown
-
-Here is a short breakdown of exactly what each macro included in
-`+ansible-packaging+` does.
-
-
-[#ansible_collection_url]
-=== `+%ansible_collection_url+`
-
-*Usage:*
-
-[source,rpm-spec]
-----
-URL:            %{ansible_collection_url NAMESPACE NAME}
-----
-
-This macro points to a collection's Ansible Galaxy page.
-It is intended to be used for the `+URL:+` tag in the specfile preamble.
-It takes the collection namespace and collection name as arguments.
-
-If no arguments are passed to this macro, it falls back to the values
-of `+%{collection_namespace}+` and `+%{collection_name}+` if they are set in the specfile.
-New packages SHOULD explicitly pass the namespace and name as arguments.
-The fallback may be removed in the future.
-See the link:#legacy_macros[Legacy Macros] section for more information.
-
-
-[#ansible_collection_build]
-
-=== `+%ansible_collection_build+`
-
-*Usage:*
-
-[source,rpm-spec]
-----
-%build
-%ansible_collection_build
-----
-
-This macro simply runs `+ansible-galaxy collection build+`.
-
-
-[#ansible_collection_install]
-=== `+%ansible_collection_install+`
-
-*Usage:*
-
-[source,rpm-spec]
-----
-%install
-%ansible_collection_install
-----
-
-This macro pulls out the collection namespace, name, and version from `+galaxy.yml+`
-and then uses it to run `+ansible-galaxy collection install+`.
-After that, it writes out `+%{ansible_collection_filelist}+` based on the
-metadata it previously extracted
-
-
-[#ansible_test_unit]
-=== `+%ansible_test_unit+`
-
-*Usage:*
-
-[source,rpm-spec]
-----
-%check
-%ansible_test_unit
-----
-This macro parses galaxy.yml to determine the collection namespace and name
-that's needed to create the directory structure that ansible-test expects.
-After creating a temporary build directory with the needed structure, the
-script runs ansible-test units with the provided arguments.
-
-
-[#ansible_collection_filelist]
-=== `+%{ansible_collection_filelist}+`
-
-*Usage:*
-
-[source,rpm-spec]
-----
-%files -f %{ansible_collection_filelist}
-%doc ...
-%license ...
-----
-
-This macro points a file list that's written out by `+%ansible_collection_install+`.
-Currently, it only contains a single entry to own the collection's entire
-directory in `+%{ansible_collections_dir}+`
-
-
-[#ansible_collections_dir]
-
-This macro expands to `+%{_datadir}/ansible/collections/ansible_collections+`.
-It is used internally by the other macros.
-Packagers are expected to use `+%ansible_collection_install+` and
-`+%ansible_collection_filelist+` instead of directly referencing this directory.
-
-[#legacy_macros]
-=== Legacy macros
-
-[#collection_namespace]
-==== `+%{collection_namepsace}+`
-*Usage:*
-
-[source,rpm-spec]
-----
-%global collection_namespace NAMESPACE
-----
-
-The ansible-packaging macros previously required
-packagers to manually set `+%collection_namespace+` in specfiles.
-Now, the macros extract the collection namespace from the `galaxy.yml`.
-
-
-[#collection_name]
-==== `+%{collection_name}+`
-
-*Usage:*
-
-[source,rpm-spec]
-----
-%global collection_name NAME
-----
-
-The ansible-packaging macros previously required
-packagers to manually set `+%collection_name+` in specfiles.
-Now, the macros extract the collection name from the `galaxy.yml`.
-
-
-[#ansible_collection_files]
-==== `+%{ansible_collection_files}+`
-
-*Usage:*
-
-[source,rpm-spec]
-----
-%files
-%doc ...
-%license ...
-%{ansible_collection_files}
-----
-
-New specfiles should use `+%files -f %{ansible_collection_filelist}+` instead
-of this macro.
-`+%{ansible_collection_files}+` requires setting
-`+%collection_namespace+` and `+%collection_name+`.
diff --git a/guidelines/modules/ROOT/pages/AppData.adoc b/guidelines/modules/ROOT/pages/AppData.adoc
deleted file mode 100644
index 18da9d9..0000000
--- a/guidelines/modules/ROOT/pages/AppData.adoc
+++ /dev/null
@@ -1,75 +0,0 @@
-= Packaging Guidelines for AppData Files
-:last-reviewed: 2021-01-18
-
-If a package contains a GUI application,
-then it SHOULD install a `+.metainfo.xml+` file
-into `+%{_metainfodir}+`.
-Installed `+.metainfo.xml+` files MUST follow
-the https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps[AppStream specification page].
-
-If a package contains an add-on for GUI application,
-then it SHOULD install a `+.metainfo.xml+` file
-into `+%{_metainfodir}+`.
-Installed `+.metainfo.xml+` files MUST follow
-the https://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html[AppStream add-ons specification].
-
-The AppData files MUST correctly validate using
-`+appstream-util validate-relax+`.
-
-.appdata.xml files
-NOTE: For historical reasons, AppStream specification also allows using
-extension `+.appdata.xml+` for GUI applications. If upstream provides metadata
-with `+.appdata.xml+` extension, it MAY be used instead of `+.metainfo.xml+`.
-
-== .metainfo.xml file creation
-
-If the package doesn't already include and install
-its own `+.metainfo.xml+` file,
-you can make your own and send it upstream.
-Some benefits of sending the file upstream are that
-upstream can translate the file using
-the existing translation resources
-and can also modify the screenshots and descriptions
-as the application changes over time.
-
-You may include an `+.metainfo.xml+` file you create
-as a Source: (e.g. `+Source3: %{name}.metainfo.xml+`)
-or generate it in the spec file.
-
-Here are the contents of a sample application `+.metainfo.xml+` file
-(comical.metainfo.xml):
-
-[source,xml]
-----
-include::{examplesdir}/app.metainfo.xml[]
-----
-
-Application's AppData file MUST be named with the same root as the .desktop file,
-so if the .desktop file is named `+org.gnome.SomeApp.desktop+`
-then the AppData file MUST be called `+org.gnome.SomeApp.metainfo.xml+`.
-
-Here are the contents of a sample addon `+.metainfo.xml+` file
-(gedit-bookmarks.metainfo.xml):
-
-[source,xml]
-....
-include::{examplesdir}/addon.metainfo.xml[]
-....
-
-You can use anything as the `+<id>+`
-but it needs to be unique and sensible
-and also match the `+.metainfo.xml+` filename prefix.
-
-== app-data-validate usage
-
-Although you can just include the .metainfo.xml file in the package,
-you MUST run `+appstream-util validate-relax+`
-(in `+%check+` or `+%install+`)
-and have `+BuildRequires: libappstream-glib+`,
-to help ensure the validity and safety
-of the appdata files you're installing.
-An example:
-
-....
-appstream-util validate-relax --nonet %{buildroot}%{_metainfodir}/*.metainfo.xml
-....
diff --git a/guidelines/modules/ROOT/pages/AutoProvidesAndRequiresFiltering.adoc b/guidelines/modules/ROOT/pages/AutoProvidesAndRequiresFiltering.adoc
deleted file mode 100644
index 4762293..0000000
--- a/guidelines/modules/ROOT/pages/AutoProvidesAndRequiresFiltering.adoc
+++ /dev/null
@@ -1,268 +0,0 @@
-= Automatic Filtering of Provides and Requires
-
-:last-reviewed: 2019-04-04
-
-== Summary
-
-The auto requires and provides system contained in RPM is quite useful;
-however, it sometimes picks up "private" package capabilities
-that shouldn't be advertised as global,
-things that are "just wrong",
-or things prohibited by policy (e.g. deps from inside `+%{_docdir}+`).
-
-For example:
-
-* Various "plugin" packages (e.g. Pidgin, Perl, Apache, KDE)
-are marked as "providing" private shared libraries outside the system path.
-* Files in `+%{_docdir}+` are routinely scanned,
-and can trigger prov/req when this is explicitly forbidden by policy.
-
-This Guideline describes how to filter provides and requires on Fedora.
-
-* *MUST:* Packages must not provide RPM dependency information
-when that information is not global in nature,
-or are otherwise handled (e.g. through a virtual provides system).
-e.g. a plugin package containing a binary shared library
-must not "provide" that library
-unless it is accessible through the system library paths.
-* *MUST:* When filtering automatically generated RPM dependency information,
-the filtering system implemented by Fedora must be used,
-except where there is a compelling reason to deviate from it.
-
-== Usage
-
-=== Location of macro invocation
-
-It's strongly recommended
-that these filtering macros be invoked before `+%description+`,
-but after any other definitions.
-This will keep them in a consistent place across packages,
-and help prevent them from being mixed up with other sections.
-
-=== Regular Expression Variant
-
-These filters use regular expressions.
-The regular expression variant used for these filters
-follows the `POSIX.2` regular expression standard
-(see the `+regex(7)+` manpage).
-In this variant,
-the literal characters `pass:c[^.[$()|*+?{]` need to be backslash escaped.
-Because rpm interprets backslashes as part of its parsing of spec files,
-you will need to use a *double backslash* for any escapes.
-A literal backslash (`+\+`) is represented by four backslashes.
-
-The regex engine is only passed the final string, after RPM macro expansion.
-So you can't use unescaped data via RPM macros.
-For instance, if you generate a list of files to match in a macro
-and that list contains `+libfoo.so+`
-you'll have to use `+libfoo\\.so+` to escape the "pass:q[`.`]".
-Example:
-
-[source, rpm-spec]
-----
-%global to_exclude libfoo\\.so
-%global __requires_exclude_from ^%{_datadir}/%{to_exclude}$
-----
-
-=== Preventing files/directories from being scanned for deps (pre-scan filtering)
-
-The macros `+%__requires_exclude_from+` and `+%__provides_exclude_from+`
-can be defined in a spec file to keep the dependency generator
-from scanning specific files or directories for deps.
-These macros should be defined with a regular expression
-that matches all of the directories or files.
-For instance:
-
-[source, rpm-spec]
-----
-# Do not check any files in docdir for requires
-%global __requires_exclude_from ^%{_docdir}/.*$
-
-# Do not check .so files in an application-specific library directory
-# or any files in the application's data directory for provides
-%global __provides_exclude_from ^(%{_libdir}/%{name}/.*\\.so.*|%{_datadir}/myapp/.*)$
-----
-
-Note that this macro replaces the `+%filter_provides_in+` macro
-from the old filtering guidelines but it does not do the same thing.
-In particular:
-
-* The old macro could be invoked multiple times.
-This one will only use the regex defined last.
-
-* The old macro advised against anchoring the beginning of the regex
-(Using `+^+`).
-This macro recommends anchoring
-as it doesn't suffer from the compatibility problems of the old one.
-* With the old macro it was common to specify a directory name
-to match everything in a directory recursively.
-With the new macro you may need to specify `+.*+`
-because you should be anchoring your regular expressions.
-
-=== Filtering provides and requires after scanning
-
-In addition to preventing RPM from scanning
-files and directories for automatic dependency generation
-you can also tell RPM to discard a discovered dependency
-before it records the dependency in the RPM metadata.
-Use `+__requires_exclude+` and `+__provides_exclude+` for this.
-These macros should be defined as regular expressions.
-If an entry that RPM's automatic dependency generator created
-matches the regular expression
-then it will be filtered out of the requires or provides.
-For example:
-
-[source, rpm-spec]
-----
-# This might be useful if plugins are being picked up by the dependency generator
-%global __provides_exclude ^libfoo-plugin\\.so.*$
-
-# Something like this could be used to prevent excess deps from an
-# example python script in %doc
-%global __requires_exclude ^/usr/bin/python$
-----
-
-These macros serves a similar purpose to the old
-`+%filter_from_provides+` macro
-but it has a different implementation.
-In particular,
-that macro took sed expressions whereas this one needs a regular expression.
-
-=== Simplified macros for common cases
-
-In some cases, the filtering of extraneous `+Provides:+`
-is fairly generic to all packages which provide similar things.
-There are simple macros that setup filters correctly
-for those cases so that you can do the filtering with one line.
-If you need to filter a bit more than the simple macro provides,
-you still have the option to use the macros listed above.
-
-==== Perl
-
-Perl extension modules can be filtered using this macro:
-
-[source, rpm-spec]
-----
-%{?perl_default_filter}
-----
-
-Essentially, this filters dependencies arising from `+%doc+` files,
-from non-Linux-related modules,
-and from errors in the automatic dependency generator.
-
-If you want to use both custom filters and `+%perl_default_filter+`
-then define your filters first and call `+%perl_default_filter+` afterwards.
-The default filter macro will preserve the filters you previously defined.
-For example:
-
-[source, rpm-spec]
-----
-# Filter all provides from some directory
-%global __provides_exclude_from %{_libexecdir}/autoinst
-# Filter some specific requires by name
-%global __requires_exclude ^perl\\((autotest|basetest)
-# All of the default filters
-%{?perl_default_filter}
-----
-
-== Examples
-
-=== Pidgin plugin package
-
-On a x86_64 machine,
-the pidgin-libnotify provides `+pidgin-libnotify.so()(64bit)+`
-which it shouldn't as this library is not inside the paths
-searched by the system for libraries.
-It's a private, not global, "provides"
-and as such must not be exposed globally by RPM.
-
-To filter this out, we could use:
-
-[source, rpm-spec]
-----
-%global __provides_exclude_from ^%{_libdir}/purple-2/.*\\.so$
-----
-
-=== Private Libraries
-
-At this time, filtering of private libraries is non-trivial.
-This is because the symbols you want to filter from the private libraries
-are usually required by the public applications that the package ships.
-In order to filter,
-you need to find out what symbols RPM is extracting for the private library
-and then remove those in both
-`+%__provides_exclude+` and `+%__requires_exclude+`.
-
-As an example, pretend you are packaging an application foo that creates
-`+%{_libdir}/foo/libprivate.so+`
-that you want to filter and
-`+%{_bindir}/foobar+`
-that requires that private library.
-You could:
-
-* First build the RPM: `+$ rpmbuild -ba foo.spec+`
-* then determine what provides rpm decided for the private library:
-`+$ rpm -qp foo-1.0-1.x86_64.rpm+`:
-
-....
-libprivate.so()(64bit)
-foo = 1.0-1.fc19
-foo(x86-64) = 1.0-1.fc19
-....
-
-* See that `+libprivate.so()(64bit)+`
-appears to be the only symbol that RPM extracted for this package.
-Note that on 32bit, the provides will be `+libprivate.so+`
-so your regex needs to capture both.
-+
-* Add the excludes to the spec file for both requires and provides:
-
-[source, rpm-spec]
-----
-[...]
-%global _privatelibs libprivate[.]so.*
-%global __provides_exclude ^(%{_privatelibs})$
-%global __requires_exclude ^(%{_privatelibs})$
-[...]
-----
-
-You can take a look at a
-https://lists.fedoraproject.org/pipermail/devel/2012-June/169190.html[more complex example]
-on the mailing list.
-This can be a pain to maintain
-if the upstream changes the names of its private libraries
-but it is the only way to deal with this at present.
-There may be a better means in
-https://lists.osuosl.org/pipermail/rpm-maint/2013-January/003349.html[the future]
-but there are no solid plans on when those might be coded as of yet..
-
-=== Arch-specific extensions to scripting languages
-
-e.g. to ensure an arch-specific `perl-*` package won't provide
-or require things that it shouldn't,
-we could use an invocation as such:
-
-[source, rpm-spec]
-----
-# we don't want to provide private Perl extension libs
-%{?perl_default_filter}
-----
-
-=== `+%{_docdir}+` filtering
-
-By policy, nothing under `+%{_docdir}+` is allowed
-to either "provide" or "require" anything.
-We can prevent this from happening
-by preventing anything under `+%{_docdir}+` from being scanned:
-
-[source, rpm-spec]
-----
-# we don't want to either provide or require anything from _docdir, per policy
-%global __provides_exclude_from ^%{_docdir}/.*$
-%global __requires_exclude_from ^%{_docdir}/.*$
-----
-
-== Additional Information
-
-Additional information about RPM's dependency generator can be found here:
-https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
diff --git a/guidelines/modules/ROOT/pages/BLAS_LAPACK.adoc b/guidelines/modules/ROOT/pages/BLAS_LAPACK.adoc
deleted file mode 100644
index 3ea9c28..0000000
--- a/guidelines/modules/ROOT/pages/BLAS_LAPACK.adoc
+++ /dev/null
@@ -1,157 +0,0 @@
-= Linear Algebra Libraries
-
-== Introduction
-
-BLAS (Basic Linear Algebra Subprograms) and LAPACK (Linear Algebra PACKage)
-are routines that provide standard building blocks for performing a wide range of linear algebra operations.
-There are stable reference implementations from https://netlib.org/[Netlib] written in Fortran,
-with C interfaces available (called CBLAS and LAPACKE respectively),
-as well as several optimized implementations providing fast subsets of these APIs.
-
-=== Available implementations
-
-* `blas`, `lapack` - Netlib's reference implementation of the Fortran and C interfaces.
-* `atlas` - Automatically Tuned Linear Algebra Software.
-* `blis` - BLAS-like Library Instantiation Software framework.
-* `openblas` - OpenBLAS, an optimized BLAS based on GotoBLAS2.
-
-ATLAS, BLIS and OpenBLAS provide BLAS and a subset of LAPACK.
-Both BLIS and OpenBLAS provide several flavors:
-a sequential version, a threaded one, and another with OpenMP support
-(all of them with or without support for 64-bit integers).
-
-Due to implementation differences, it is important that all components of a particular software stack link to the same BLAS/LAPACK implementation.
-Also, users may want to choose a particular implementation that works best for them at run time.
-This guideline gives a structure that can enforce the first while allowing the second,
-as well as providing a transparent fallback mechanism to Netlib's reference implementation for those symbols not included in the selected backend
-via https://www.mpi-magdeburg.mpg.de/projects/flexiblas[FlexiBLAS].
-
-=== BLAS/LAPACK wrapper
-
-https://www.mpi-magdeburg.mpg.de/projects/flexiblas[FlexiBLAS]
-is a framework that wraps both BLAS and LAPACK APIs in a single library. 
-BLAS/LAPACK consumers must link against FlexiBLAS,
-and this wrapper is able to redirect calls to a selected optimized backend with negligible overhead.
-It also provides transparent fallback to Netlib's reference implementation if a certain symbol is not present in the selected backend.
-These are the main features:
-
-* Provides a 100% BLAS and LAPACK compatible ABI/API, with interfaces for both 32- and 64-bit integers.
-* Runtime exchangeable BLAS and LAPACK backend without recompilation via an environment variable.
-* Integration of user-owned BLAS libraries without administrator privileges, even in system-wide installed programs.
-* Works with OpenBLAS, ATLAS and BLIS, as well as non-free alternatives such as Intel MKL, ACML...
-* Flexible per-system/user/host configuration files.
-* Basic profiling support.
-
-[NOTE]
-====
-Fedora ships `openblas-openmp` as the system-wide default backend.
-====
-
-== Packaging BLAS/LAPACK dependent packages
-
-Consumers of any subset of BLAS and/or LAPACK MUST compile against FlexiBLAS (unless not supported; see below).
-
-[NOTE]
-====
-.Exceptions
-* Although support for LAPACKE is planned, the few packages using this interface are not yet supported by FlexiBLAS as of v3.1.2.
-  These packages MUST link against OpenBLAS instead, or `lapack` if the routines used are not supported by this backend.
-  Current exceptions of this type include `opencv`, `scamp` and `sextractor`.
-* On rare occasions, a package may use an exceptional feature present in a particular backend
-  and cannot be adapted to FlexiBLAS by any means.
-  In such cases, the package MUST link against this backend.
-  Current exceptions of this type include `julia` (linked against OpenBLAS) and `psfex` (linked against ATLAS).
-====
-
-=== Build requirements
-
-First, only FlexiBLAS's development package MUST be listed in `BuildRequires`:
-
-....
-BuildRequires: flexiblas-devel
-....
-
-which brings all the necessary development files,
-both for the 32-bit (the most common) and the 64-bit integer interface.
-
-[IMPORTANT]
-====
-If the package *only* supports the interface for 64-bit integers,
-then 32-bit architectures MUST be excluded
-(see xref:index.adoc#_arch_specific_runtime_and_build_time_dependencies[Arch-Specific Runtime and Build-Time Dependencies]).
-====
-
-=== Configuration
-
-The packager MUST specify `flexiblas` or `flexiblas64`
-(for the 32-bit or 64-bit interface respectively)
-as both the BLAS and LAPACK library names where applicable,
-and packages using `pkg-config` will automatically obtain the proper flags for the headers and libraries.
-Similarly, CMake-based projects using `FindBLAS` will automatically detect
-and configure the proper flags for FlexiBLAS (since CMake v3.19),
-and no further action will be required from the packager.
-
-Unfortunately, many upstream projects present heterogeneous ways of accessing these APIs.
-In a best-case scenario, the building framework may define specific options to explicitly set the BLAS and/or LAPACK libraries.
-More commonly, the packager MUST ensure that `+%{_includedir}/flexiblas+` and `+%{_libdir}/flexiblas+`
-(or `+%{_includedir}/flexiblas64+` and `+%{_libdir}/flexiblas64+`)
-are injected as header and library locations in the proper flags and configuration files,
-and/or `-lflexiblas` (or `-lflexiblas64`) is provided to the linker.
-In rare occasions, hardcoded paths in source files MUST be modified, and patches MAY be required.
-The packager SHOULD work with upstream to standardize the way in which these libraries are detected and configured.
-
-[IMPORTANT]
-====
-To ensure that the program has been properly linked against FlexiBLAS,
-the packager MUST check that the `Requires` are correct,
-i.e., `libflexiblas` is listed, but not `libblas`, `liblapack` or any other backend.
-====
-
-=== Tests
-
-Optimized BLAS/LAPACK backends are much faster than Netlib's reference implementation,
-but in return results may vary a little.
-Consequently, tests that are too tight (with too small tolerances) may fail.
-In these cases, the packager SHOULD enable the reference implementation in the `%check` section as follows:
-
-....
-export FLEXIBLAS=netlib
-....
-
-or, alternatively, via `FLEXIBLAS64` for builds using 64-bit integers.
-
-== Backend selection
-
-=== System-level selection
-
-A package compiled against FlexiBLAS pulls out the corresponding `flexiblas-netlib(64)` subpackage,
-which in turn requires the default optimized backend (i.e., `flexiblas-openblas-openmp(64)`).
-This is set via the "default=IMPLEMENTATION-NAME" key (by default, `default=openblas-openmp`),
-present in the main configuration file shipped in the main subpackages,
-`+%{_sysconfdir}/flexiblasrc+` and `+%{_sysconfdir}/flexiblas64rc+`.
-
-To allow system-level selection of other BLAS/LAPACK implementations,
-more backends must be installed in the first place (e.g., flexiblas-atlas, flexiblas-blis-serial...),
-and then they can be swapped system-wide via the `flexiblas` CLI tool,
-or just by modifying the "default" key in the configuration file by hand.
-
-=== User-level selection
-
-Persistent user-level selection of system-provided BLAS/LAPACK implementations can be done via the CLI tool:
-
-....
-$ flexiblas set IMPLEMENTATION-NAME
-$ flexiblas64 set IMPLEMENTATION-NAME
-....
-
-provided the sub-package for `IMPLEMENTATION-NAME` is installed.
-
-Non-persistent user-level selection can be triggered via an environment variable:
-
-....
-$ FLEXIBLAS=IMPLEMENTATION-NAME ./yourapp
-$ FLEXIBLAS64=IMPLEMENTATION-NAME ./yourapp64
-....
-
-User-level selection of user-owned BLAS/LAPACK libraries can be achieved just by changing `IMPLEMENTATION-NAME`
-with a path to any custom BLAS/LAPACK-compatible library in the examples above.
diff --git a/guidelines/modules/ROOT/pages/CMake.adoc b/guidelines/modules/ROOT/pages/CMake.adoc
deleted file mode 100644
index 8bbacb6..0000000
--- a/guidelines/modules/ROOT/pages/CMake.adoc
+++ /dev/null
@@ -1,113 +0,0 @@
-:last-reviewed: 2020-07-18
-
-= CMake Packaging Guidelines
-
-This document provides best practices for the usage of
-https://cmake.org/[the CMake build system]
-in Fedora packages.
-
-== Build Dependencies
-
-You *MUST* add following BuildRequires:
-
-[source, rpm-spec]
-----
-BuildRequires: cmake
-----
-
-== Available Macros
-
-You will generally make use of these in your specs:
-
-`+%cmake+`::
-Defines CFLAGS, LDFLAGS, etc. and calls `+%__cmake+`
-with appropriate parameters
-(`+-DCMAKE_INSTALL_PREFIX:PATH=/usr+` and such).
-You can pass `+-Doption=value+` to this macro
-in order to set options for the buildsystem.
-
-`+%cmake_build+`::
-Builds the project (using `+%__cmake --build+`).
-
-`+%cmake_install+`::
-Installs the built project (using `+%__cmake --install+`).
-
-`+%ctest+`::
-Runs the tests that are defined with `+add_test()+`
-in project (using `+%__ctest+`).
-
-When packaging KDE software,
-you most likely would replace `+%cmake+` with either `+%cmake_kf5+`
-or `+%cmake_kf6+`. For more information, see xref:KDEPackaging.adoc[KDE Packaging Guidelines].
-
-It is rarely necessary (but permissible) to use or alter these:
-
-NOTE: All macros starting with double underscore is meant to be private,
-NOT stable and likely to be removed in the future.
-
-`+%__cmake+`::
-The path to the cmake executable.
-
-`+%__ctest+`::
-The path to the ctest executable.
-
-`+%__cmake_in_source_build+`::
-Controls whether builds are done
-https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds[out-of-source]
-(when undefined, the default)
-or in-source (when defined).
-Whenever possible, using out-of-source builds is advised,
-as this is the direction both Fedora and CMake upstream are moving.
-
-`+%__cmake_builddir+`::
-Holds the location of the actual directory where the build was made.
-When making out-of-source builds,
-this macro is the same as xref:vpath.adoc[%_vpath_builddir].
-When doing in-source builds,
-this macro will hold the actual location that was used for the build.
-+
-WARNING: This macro is suitable only for rare compatibility reasons.
-For normal out-of-source builds, this macro is the same as `+%_vpath_builddir+`.
-It may be removed in the future.
-
-== Example Usage
-
-[source, rpm-spec]
-----
-%conf
-%cmake
-
-%build
-%cmake_build
-
-%install
-%cmake_install
-
-%check
-%ctest
-----
-
-*NOTE:* If building for < EPEL 10 then `%cmake` should be in `%build`.
-
-== Notes
-
-`+-DCMAKE_SKIP_RPATH:BOOL=ON+`.
-With recent cmake-2.4, it should not be used.
-This CMake version should handle RPATHs issues correctly
-(set them in build-dir, remove them during installation).
-Setting `+CMAKE_SKIP_RPATH+` for this version
-would avoid RPATHs in build-dir too.
-This might link binaries against system-libraries
-(e.g. when a previous version of the package was installed)
-instead of the libraries which were created by the build.
-
-Nevertheless, RPATH issues might arise when CMake was used improperly.
-For example, installing a target with `+INSTALL(FILES ... RENAME ...)+`
-will *not* strip rpaths;
-in this case `+INSTALL(TARGETS ...)+` must be used
-in combination with changing the `+OUTPUT_NAME+` property.
-
-CMake has good documentation in two places:
-
-* https://cmake.org/documentation/
-* https://gitlab.kitware.com/cmake/community/wikis/Home
diff --git a/guidelines/modules/ROOT/pages/C_and_C++.adoc b/guidelines/modules/ROOT/pages/C_and_C++.adoc
deleted file mode 100644
index 8af3669..0000000
--- a/guidelines/modules/ROOT/pages/C_and_C++.adoc
+++ /dev/null
@@ -1,180 +0,0 @@
-= C and C++ Packaging Guidelines
-// https://github.com/asciidoctor/asciidoctor/commit/426d8389aa1706a589b66c96801542f587ae6b61
-:pp: ++
-
-== Introduction
-
-The C and {cpp} languages and runtimes
-are one of the most common development frameworks for packages in fedora.
-As such there is a wide variety of quality, style, and convention
-in all of those packages.
-The follow document provides best practice
-for certain aspects of C and {cpp} packaging.
-
-== Packaging
-
-=== BuildRequires and Requires
-
-If your application is a C or {cpp} application
-you must list a `BuildRequires` against `gcc`, `gcc-c{pp}` or `clang`.
-Those packages will include everything that is required
-to build a standards conforming C or {cpp} application.
-
-If your library includes standard C or {cpp} headers,
-you must list `BuildRequires` against `gcc`, `gcc-c{pp}`, or `clang`
-to install the needed standards conforming headers.
-
-If at runtime you use `cpp` to process C or {cpp} language headers
-then you have no choice but to use `Requires` for `gcc`, `gcc-c{pp}`, or `clang`
-to install the required headers
-for a standard conforming C or {cpp} application.
-In the future this might change
-if a set of standard C or {cpp} language headers are provided
-by a special-purpose provides e.g. `c-headers` or `c{pp}-headers`.
-
-You need not include a `BuildRequires` or `Requires` on `glibc-headers`,
-or any other core C or {cpp} implementation package
-unless you have a specific and special need
-e.g. static compilation requires the `.*-static` library packages
-e.g. `BuildRequires: glibc-static`.
-The default use case of a dynamically compiled C or {cpp} application
-is taken care of by the `gcc`, `gcc-c{pp}`, and `clang` packages.
-
-Please refer to xref:index.adoc#compiler[Compiler Guidelines]
-for the list of supported compilers for C and {cpp} compilers.
-
-=== Packaging Q&A
-
-[qanda]
-Do I need a `Requires: glibc` to ensure I have the C runtime installed for my application?::
-No.
-RPM will automatically determine what ELF libraries you need
-based on the binaries in your package.
-This is sufficient to cause glibc to be installed.
-
-Do I need to include a `Requires: libgcc`?::
-If you are using an API from `libgcc` directly,
-then yes, you must have a `Requires: libgcc`.
-In general though `glibc` requires `libgcc`, so it is always installed.
-
-== Libraries
-
-Libraries should have unique shared object names
-(SONAMEs via `-Wl,-soname=libfoo.so`)
-that do not conflict with other library SONAMEs used in the distribution.
-For example there should be only one `libfoo.so` in the distribution.
-The exception is when there are multiple implementations of the same library
-`libfoo.so` provided by different authors and each conflicts with the other.
-In this case both `libfoo.so` must provide exactly the same interface,
-but with a different implementation.
-Having two `libfoo.so` each with a different API is bad practice
-and makes it harder to package and distribute those packages.
-
-== Versioned Symbols
-
-Without versioned symbols, RPM will generate a dependency expression
-naming the library but without a version, effectively setting
-"$Major.0.0" as the minimum version. Versioned symbols provide the
-information required to ensure that libraries are actually new enough
-to run the software that links to them.
-
-Examine the capabilities provided by the binary rpm:
-`rpm -qp --provides <package>`.  A package with shared libraries will
-list the library as `libc.so.6()(64bit)` and if the library provides
-versioned symbols it will also list the library with versions as
-`libm.so.6(GLIBC_2.41)(64bit)`.
-
-Package maintainers are encouraged to work with upstream projects to
-add versioned symbols to libraries that do not include them yet.
-
-Adding symbol versions is simple for the majority of libraries,
-initially requiring only a symbol map and one additional argument to
-the linker during the build process.
-
-```
-generate_initial_map.sh:
-#!/bin/sh
-echo "# Avoid modifying a symbol set after it has been released"
-echo "# When adding features in a new release, add a new set"
-echo "# Removing features is a breaking change"
-echo "$2 {"
-echo "  global:"
-objdump -T $1 | \
-  grep -F .text | \
-  awk '{print $7;}' | \
-  c++filt | \
-  awk '/[() ]/ {print "    \"" $0 "\";";} \
-      !/[() ]/ {print "    " $0 ";";}' | \
-  sort
-echo "}"
-```
-
-Run `generate_initial_map.sh /path/to/library.so.1 <LIBRARY>_<VERSION>` to
-generate a map file.
-
-=== Adding version-script to Automake
-
-The GNU Portability Library link:https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html[manual]
-includes examples of using version-script in automake. In Makefile.am:
-
-```
-if HAVE_LD_VERSION_SCRIPT
-libfoo_la_LDFLAGS += -Wl,--version-script=$(srcdir)/libfoo.map
-endif
-```
-
-=== Adding version-script to CMake
-
-The BSD-3-Clause licensed link:https://github.com/protocolbuffers/protobuf[protobuf]
-project includes examples of using version-script in CMake.
-
-In CMakeLists.txt, check the linker for support:
-
-```
-file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/cmaketest.map
-"{
-  global:
-    main;
-  local:
-    *;
-};")
-# CheckLinkerFlag module available in CMake >=3.18.
-if(${CMAKE_VERSION} VERSION_GREATER_EQUAL 3.18)
-  include(CheckLinkerFlag)
-  check_linker_flag(CXX -Wl,--version-script=${CMAKE_CURRENT_BINARY_DIR}/cmaketest.map project_HAVE_LD_VERSION_SCRIPT)
-endif()
-file(REMOVE ${CMAKE_CURRENT_BINARY_DIR}/cmaketest.map)
-```
-
-And, where the library is defined:
-
-```
-if(project_HAVE_LD_VERSION_SCRIPT)
-  target_link_options(libfoo PRIVATE -Wl,--version-script=${protobuf_source_dir}/src/libfoo.map)
-  set_target_properties(libfoo PROPERTIES
-    LINK_DEPENDS ${project_source_dir}/src/libfoo.map)
-endif()
-```
-
-=== Adding version-script to Meson
-
-Meson's link:https://github.com/mesonbuild/meson/blob/master/test%20cases/linuxlike/3%20linker%20script/meson.build[test cases]
-include examples of using version-script.
-
-```
-# Solaris 11.4 ld supports --version-script only when you also specify
-# -z gnu-version-script-compat
-if meson.get_compiler('c').get_linker_id() == 'ld.solaris'
-  add_project_link_arguments('-Wl,-z,gnu-version-script-compat', language: 'C')
-endif
-
-# Static map file
-mapfile = 'bob.map'
-vflag = '-Wl,--version-script,@0@/@1@'.format(meson.current_source_dir(), mapfile)
-
-l = shared_library('bob', 'bob.c', link_args : vflag, link_depends : mapfile)
-```
-
-== Applications
-
-No additional suggestions are provided for applications at this time.
diff --git a/guidelines/modules/ROOT/pages/Conflicts.adoc b/guidelines/modules/ROOT/pages/Conflicts.adoc
deleted file mode 100644
index 38b1179..0000000
--- a/guidelines/modules/ROOT/pages/Conflicts.adoc
+++ /dev/null
@@ -1,298 +0,0 @@
-include::{partialsdir}/attributes.adoc[]
-
-= Conflicts Guidelines
-
-*Author:* https://fedoraproject.org/wiki/TomCallaway[ Tom 'spot' Callaway] +
-*Revision:* 0.07 +
-*Initial Draft:* Tuesday Dec 5, 2006 +
-*Last Revised:* Wednesday Oct 31, 2012 +
-
-
-== Conflicts
-
-Users should always be able to install the latest packages from Fedora's repos
-regardless of what other Fedora packages are installed.
-Therefore, whenever possible,
-the latest Fedora packages of a release
-should avoid conflicting with each other.
-Conflicts result in a transaction set
-where the user has to decipher the error message
-and make some sort of decision.
-The transaction set doesn't provide information to the user
-about why two packages conflict to help them make an informed decision.
-
-As Fedora packagers,
-we try to make it so that any subset of latest Fedora's packages
-will install and run.
-Unfortunately, this is not always possible
-but we can usually make it so that conflicting packages can be installed
-and the user can decide which package to enable afterwards.
-In the few remaining cases, we have to use `+Conflicts:+` tags.
-These guidelines illustrate how conflicts should be handled in Fedora,
-specifically concerning when and when not to use the `+Conflicts:+` field.
-
-== Acceptable Uses of Conflicts:
-
-As a general rule,
-Fedora packages must NOT contain any usage of the `+Conflicts:+` field.
-This field is commonly misused,
-when a `+Requires:+` would usually be more appropriate.
-It confuses depsolvers and end-users for no good reason.
-However, there are some cases in which using the `+Conflicts:+` field
-is appropriate and acceptable.
-
-=== Implicit Conflicts
-
-Keep in mind that implicit conflicts are NEVER acceptable.
-If your package conflicts with another package,
-then you must either resolve the conflict, or mark it with `+Conflicts:+`.
-
-=== Optional Functionality
-
-Some software can utilize other optional software applications if present,
-but do not require them to be installed.
-If they are not installed, the software will still function properly.
-However, if those other "optional applications" are too old,
-then the software won't work.
-This is an acceptable use of the `+Conflicts:+` field.
-The packager must document the reason in a comment
-above the `+Conflicts:+` field:
-
-*Example:*
-
-[source, rpm-spec]
-----
-Conflicts: unrar < 2.0
-----
-
-If the software links to the libraries of another package,
-it must use `+Requires:+` instead of `+Conflicts:+` to mark that dependency.
-Also, if the software does not function properly
-without another package being installed,
-it must use `+Requires:+` instead of `+Conflicts:+`.
-
-The packager should ask:
-
-_If the package (at the correct version) in Conflicts: is not present,
-will my package be functional?_
-
-If the answer is yes, then it is probably a valid use of `+Conflicts:+`.
-If the answer is no,
-then it is almost certainly a better case for `+Requires:+`.
-
-For example, if foo-game needs libbar to run,
-but will not work with libbar that is older than 1.2.3:
-
-*WRONG:* Conflicts: libbar < 1.2.3 +
-*RIGHT:* Requires: libbar >= 1.2.3 +
-Packagers should keep usage of `+Conflicts:+` to a bare minimum.
-Only upgrading from two previous release of Fedora is supported,
-so Conflicts against older packages than that, while technically correct,
-are unnecessary, and should not be included.
-
-=== Splitting Packages
-
-If contents from one package are split into a separate package
-the new package usually contains files that also appear in the original package
-which might lead to a implicit conflict
-between the files in the new package and the original package.
-Where the new package depends on the original package,
-this can be resolved with a versioned Requires:
-
-[source, rpm-spec]
-----
-# In the new package's spec file:
-Requires: original-package > EVR_BEFORE_SPLIT
-----
-
-If the new package should be installable
-independently of whether the original package is installed,
-a versioned conflict is allowed:
-
-[source, rpm-spec]
-----
-# In the new package's spec file:
-Conflicts: original-package <= EVR_BEFORE_SPLIT
-----
-
-In both of these cases,
-the new version of the original package should be updated
-to not contain the conflicting files
-and to depend on the new package
-(at least in all stable Fedora releases).
-This allows to install the latest releases of both packages without any problem.
-The Conflicts are only there to resolve the case
-where the new package is installed
-and the older version of the original package was already installed.
-
-=== Compat Package Conflicts
-
-It is acceptable to use `+Conflicts:+` in some cases involving compat packages.
-These are the cases where it is not feasible to patch applications
-to look in alternate locations for the -compat files,
-so the foo-devel and foo-compat-devel packages need to `+Conflict:+`.
-Whenever possible, this should be avoided.
-
-=== Incompatible Binary Files with Conflicting Naming (and stubborn upstreams)
-
-In the specific case
-where multiple software components generate identically named
-(but incompatible) binaries,
-Fedora Packagers should make every effort to convince the upstreams
-to rename the binaries to resolve the conflict
-(see: xref:#_binary_name_conflicts[Binary Name Conflicts]).
-However, if neither upstream is willing to rename the binaries
-to resolve the conflict,
-*AND* the binaries are not viable candidates for alternatives
-or environment modules (incompatible runtimes),
-as long as there are no clear cases for both packages
-to be installed simultaneously,
-explicit Conflicts are permitted at the packager's discretion.
-Both packages must carry Conflicts in this case.
-
-Be aware, adding explicit Conflicts means that
-if any other packages depend on your package,
-you may be creating a chain-of-conflicts that could cause user pain.
-Please consider this as a last resort.
-
-== Common Conflicting Files Cases and Solutions
-
-There are many types of files which can conflict between multiple packages.
-Fedora strongly discourages using `+Conflicts:+` to resolve these cases.
-Here are some suggestions which can be used to resolve these conflicts
-(note that not all file conflict cases are listed,
-nor are all possible solutions):
-
-=== Man Page Name Conflicts
-
-* Rename the man pages to slightly alter the suffix of the man page
-(e.g man1/check.1.gz and man1/check.1foo.gz)
-
-* Rename the man pages to include a prefix of the providing package
-(e.g. foo-check.1.gz and bar-check.1.gz)
-
-=== Library Name Conflicts
-
-If the library is 100% ABI-compatible, you can use
-xref:EnvironmentModules.adoc[Environment Modules]
-to let the user switch between them.
-If the library is not 100% ABI-compatible get one of the upstreams to rename.
-See xref:#_approaching_upstream[Approaching Upstream] for ideas on persuasion.
-If neither upstream will budge open a ticket for the {packaging-committee}
-to evaluate what sort of hoops both packages would need to implement
-to not conflict at runtime.
-
-=== Header Name Conflicts
-
-* Put the headers in a subdirectory of /usr/include.
-
-=== Binary Name Conflicts
-
-* Convince upstream to rename the binaries to something less generic
-(or just less conflicting).
-* In the case where the conflicting binaries provide the same functionality,
-you can then rename the binaries with a prefix,
-and use xref:Alternatives.adoc[Alternatives]
-to let the system administrator select which generic name is the default.
-Note that this is usually not the case.
-
-* In cases where the binaries provide similar functionality
-xref:EnvironmentModules.adoc[EnvironmentModules] may be an option.
-This is more flexible than alternatives
-and is for things that each individual on a system may want to choose between
-rather than a system administrator.
-
-
-=== Approaching Upstream
-
-When renaming or putting files into subdirectories,
-it is a good idea to try to get upstream to rename their conflicting files
-(for instance if they both had commands named %\{_bindir}/trash).
-Doing some research about which has been around longer may be useful
-in this case but may or may not be persuasive to upstream.
-
-If neither upstream renames, we would then approach other distributions
-(distributions-list[at]freedesktop.org is a good place to discuss this)
-about renaming that can be done in all distros.
-That helps end users going from one distro to another to have consistency.
-Length of time that the projects have been around,
-how popular each is,
-and numerous other factors may play a role in this decision.
-Once a decision is made, we would rename the Fedora packages to match.
-
-== Potential Conflicting Files
-
-We don't just try to avoid conflicts with existing packages within Fedora
-but also potential conflicts.
-This is because the first package to enter Fedora
-is not always the one that should take on the name.
-There are several scenarios in which this could come into play:
-
-1.  There is a conflicting package that is not in Fedora yet
-(found by doing a web search, for instance)
-
-2.  There is no conflict yet
-but the filename is likely to be used by another project
-(something like `+/usr/bin/parser+`)
-
-In the first case, where a conflicting package is known to exist
-but is not yet in Fedora,
-we should go through the process of determining
-which package has a more valid claim to the name
-and rename the files in the package we're including
-if it doesn't have the more valid claim.
-If you think your situation is unique, please open a ticket
-with the {packaging-committee}.
-
-In the second case,
-where there is no known package to conflict with at this time,
-it is up to the packager to make a decision.
-Note that it is encouraged that you at least speak to upstream
-about the potential for conflicts.
-However, we can hope that any later projects that attempt to use that name
-can be persuaded to rename based on this project being around longer.
-
-=== Standard Commands
-
-Common names are allowed for standard commands
-since those will be the only commands to implement them.
-Standard commands include
-things provided for in published and widely implemented standards like POSIX
-and de facto standards
-such as a program that has traditionally been shipped
-with a certain filename
-as part of a large number of Unix variants.
-If in doubt, send a message to fedora-devel-list[at]redhat.com
-with details of what standards the command appears in,
-how long it's been available on what Unix systems,
-and whether you've found any conflicting programs
-that implement a substantially different command with the same filename.
-
-== Conflicting Package Names
-
-Just as files can conflict, package names can as well.
-Conflicting package names *MUST* be resolved.
-Package names which differ only in case are still considered to be conflicting.
-You should follow the same basic steps outlined in
-xref:#_approaching_upstream[Approaching Upstream].
-
-Renaming packages and replacing them with others can be difficult
-if it has to occur at a later time
-(for instance, upgrade paths can become complex in these situations)
-so it is even more important to be aware of potential conflicts here
-than it is with filenames.
-
-== Other Uses of Conflicts:
-
-If you find yourself in a situation
-where you feel that your package has to conflict with another package
-(either explicitly or implicitly),
-but does not fit the documented accepted cases above,
-then you need to make your case to the
-https://pagure.io/packaging-committee[Fedora Packaging Committee].
-If they agree, then, and only then
-can you use `+Conflicts:+` in a Fedora package.
-Remember, whenever you use `+Conflicts:+`,
-you are also required to include the reasoning
-in a comment next to the `+Conflicts:+` entry,
-so that it will be abundantly clear why it needed to exist.
diff --git a/guidelines/modules/ROOT/pages/CronFiles.adoc b/guidelines/modules/ROOT/pages/CronFiles.adoc
deleted file mode 100644
index 716ad98..0000000
--- a/guidelines/modules/ROOT/pages/CronFiles.adoc
+++ /dev/null
@@ -1,102 +0,0 @@
-= Fedora Cron Job Files
-
-This document describes the guidelines for packaging cron job files in Fedora.
-
-For the purposes of these guidelines,
-a cron job file is defined as a script (e.g., a shell script or a Perl script).
-These cron job files are scheduled to run on regular intervals by a cron daemon.
-
-== Cron Job Files on the filesystem
-
-Packages with cron job files must place those cron job files into
-one or more of the following directories
-/etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly
-depending on the intended interval they should run.
-
-There is an exception to this rule:
-If a certain cron job has to be executed at some frequency
-or at a specific time interval other than the above,
-then a custom crontab file should be added to /etc/cron.d
-(with 0640 permissions).
-In this case, the cron job file (the script)
-must be placed in an appropriate system location
-(e.g. %\{_bindir}, %\{_libexecdir}), and NOT in /etc/cron.d.
-
-Both cron job files and crontab definition files
-installed in any of these directories
-must be treated as configuration files
-so that they can easily be modified by the local system administrator.
-
-== Cron Job file
-
-A typical cron job file is just a script like
-
-....
-#!/bin/sh
-# My cron job script
-# set -x
-
-echo "This is my simple cron job script"
-
-exit 0
-....
-
-Example of crontab definition run at ever other hour
-specified in /etc/cron.d/example
-
-....
-# .---------------- minute (0 - 59)
-# |  .------------- hour (0 - 23)
-# |  |  .---------- day of month (1 - 31)
-# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
-# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
-# |  |  |  |  |
-# *  *  *  *  * user-name  command to be executed
-
-0 */2 * * * root /usr/bin/example
-....
-
-== Cron job file names
-
-The file name of a cron job file should match
-the name of the package from which it comes.
-
-If a package supplies multiple cron job files files in the same directory,
-the file names should all start with the name of the package
-followed by a hyphen (-) and a suitable suffix.
-
-== Cron Job Files Packaging
-
-Cron job file(s) in packages must be marked as %config(noreplace),
-and their filename(s) should match the name of the package.
-
-Helper files used by cron job files should be placed
-in appropriate system locations
-(e.g. %\{_bindir} or %\{_libexecdir})
-and do not need to be marked as %config.
-
-Packages with cron job files must have an explicit
-`+Requires: crontabs+`.
-Since `+crontabs+` requires `+/etc/cron.d+`
-and all cron daemon packages create (and own) that directory,
-`+crontabs+` serves as a virtual requires for cron daemon functionality.
-
-=== Example of cron job packaging
-
-[source, rpm-spec]
-----
-Name:
-...
-Source1: %{name}.cron
-Requires: crontabs
-
-...
-
-%install 
-...
-mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/cron.monthly
-%{__install} -p -D -m 0750 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/cron.monthly/%{name}
-
-%files
-%config(noreplace) %{_sysconfdir}/cron.monthly/%{name}
-----
diff --git a/guidelines/modules/ROOT/pages/CryptoPolicies.adoc b/guidelines/modules/ROOT/pages/CryptoPolicies.adoc
deleted file mode 100644
index b9c033b..0000000
--- a/guidelines/modules/ROOT/pages/CryptoPolicies.adoc
+++ /dev/null
@@ -1,110 +0,0 @@
-= Crypto Policies
-
-== Enforcing system crypto policies
-
-In Fedora there are policies for the usage of cryptographic protocols
-such as TLS that are enforced system-wide.
-Each application being added in Fedora must be checked
-to comply with the policies.
-Currently the policies are restricted to major libraries
-such as GnuTLS, OpenSSL, NSS, libkrb5,
-languages such as Java and major applications like OpenSSH and bind.
-The rpmlint tool will warn when it detects that some action has to be taken;
-that detection is based on heuristics
-and limited to C programs,
-so manual inspection is recommended.
-Note however,
-that there are applications which intentionally set weaker,
-or custom settings on a purpose
-(e.g., postfix);
-those need not adhere to the policy.
-When in doubt,
-discuss with the
-https://lists.fedoraproject.org/admin/lists/crypto-team.lists.fedoraproject.org/[Fedora crypto team].
-
-=== New crypto libraries
-
-New crypto libraries must comply with the crypto policies to enter Fedora,
-unless an exception has been granted by Fedora packaging committee.
-If you wish to submit a package which does not comply with the crypto policies,
-you MUST first consult with the
-https://lists.fedoraproject.org/admin/lists/crypto-team.lists.fedoraproject.org/[Fedora crypto team].
-Once their approval has been granted,
-open a ticket with the
-https://pagure.io/packaging-committee[Fedora Packaging Committee]
-requesting an exemption.  Please link to any relevant discussion.
-
-=== C/C++ applications
-
-* *OpenSSL applications*:
-** _If the application provides a configuration file_
-that allows to modify the cipher list string,
-ensure that the shipped file contains "PROFILE=SYSTEM" as default.
-In that case no further action is required.
-
-** _If the application doesn't have a configuration file_,
-ensure that there is no default cipher list specified,
-or that the default list is set as "PROFILE=SYSTEM".
-That is, check the source code for *SSL_CTX_set_cipher_list*().
-If it is not present then nothing needs to be done (the default is used).
-Otherwise, if that call is present
-and provided a fixed string which does not contain PSK or SRP,
-replace the string with "PROFILE=SYSTEM",
-or remove the call.
-
-* *GnuTLS applications*:
-** _If the application provides a configuration file_
-that allows to modify the cipher priority string,
-the shipped file contains "@SYSTEM" as default.
-In that case no further action is required.
-** _If the application doesn't have a configuration file_,
-ensure that it uses gnutls_set_default_priority(),
-or that the default priority string is "@SYSTEM".
-That is, check the source code for *gnutls_priority_set_direct*(),
-*gnutls_priority_init*();
-if they are not present and gnutls_set_default_priority() is used,
-nothing needs to be done.
-Otherwise check the strings provided by the application.
-If it contains PSK or SRP do nothing
-(these applications are not currently covered by the default policy).
-If not, then replace gnutls_priority_set_direct()
-with gnutls_set_default_priority().
-If gnutls_priority_init() is used instead with a fixed string,
-replace the string with "@SYSTEM".
-
-Applications utilizing other cryptographic libraries
-do not adhere to the system wide crypto policies
-(note that adherence to the system-wide policies
-is work in progress for NSS libraries)
- Applications in Fedora should use one of these libraries
-when there is choice,
-and preferrably the version recommended by upstream.
-
-=== Perl applications
-
-* *IO::Socket::SSL Perl applications*:
-** Check the source code for passing *SSL_cipher_list* argument
-to *IO::Socket::SSL*'s methods like *new()*,
-*start_SSL()*,
-*new_from_fd()*,
-*set_defaults()*,
-*set_client_defaults()*,
-and *set_server_defaults()*.
-If it is not present then nothing needs to be done (the default is used).
-Otherwise, if that argument is present,
-remove the argument or change its value as described in OpenSSL section.
-
-* *Net::SSLeay Perl applications*:
-** Check the source code for *CTX_set_cipher_list()*,
-*set_cipher_list()*,
-and *set_pref_cipher()* subroutine calls
-from *Net::SSLeay* name space.
-If such a call presents,
-follow instructions described in the OpenSSL section.
-
-* *LWP::UserAgent Perl applications*:
-** Check the source code for passing *SSL_cipher_list* argument
-to *ssl_opts()* method call
-on a *LWP::UserAgent* object.
-If such a call presents,
-follow instructions described in the OpenSSL section.
diff --git a/guidelines/modules/ROOT/pages/D.adoc b/guidelines/modules/ROOT/pages/D.adoc
deleted file mode 100644
index a7fdc08..0000000
--- a/guidelines/modules/ROOT/pages/D.adoc
+++ /dev/null
@@ -1,108 +0,0 @@
-= D Packaging Guidelines
-
-== ldc
-
-All D packages depend on ldc to build, so every package must have ldc as BuildRequires. In addition, the ldc package includes some useful macros for D packages.
-
-=== Compiler options
-
-`+%{_d_optflags}+` must be used with ldc (normal `+%{optflags}+` do not apply to ldc, only to gcc).
-
-`+%{_d_optflags}+` is defined as:
-
-....
--release -w -g -O2
-....
-
--release _disables asserts, invariants, contracts and boundscheck_ +
--w _enables warnings_ +
--g _generates debug information_ +
--O2 _is the optimisation level_
-
-Some D packages use Makefiles, which usually use the $DFLAGS variable in the same way that C packages with Makefiles use $CFLAGS. In this case, `+export DFLAGS="%{_d_optflags}"+` is usually appropriate. In other cases, the build script in the D package has an option to pass in `+%{_d_optflags}+`. It is the responsibility of the packager to ensure that `+%{_d_optflags}+` are used with ldc when the package is built.
-
-=== Header Files
-
-D packages contain header files, which end with .d or .di. These header files must be installed into `+%{_d_includedir}/%{name}+`.
-
-`+%{_d_includedir}+` is defined as:
-
-....
-/usr/include/d/
-....
-
-== Libraries
-
-At this time, Linux does not support shared libraries for D code (only OSX does).
-As a result, D packages are explicitly excluded from the restrictions against packaging static libraries.
-
-To build static libraries in D, you use the same tools that you would for C, specifically, ar, ranlib, and strip.
-
-If your D package contains static libraries, you must disable debuginfo generation, by adding this line to the top of your spec file:
-
-....
-%global debug_package %{nil}
-....
-
-Otherwise, it would generate an empty debuginfo package.
-
-All static libraries must be placed in the *-devel subpackage. When doing this, you must also have
-`+Provides: %{name}-static = %{version}-%{release}+` in the devel package definition.
-
-It is possible that this will leave the root package empty, if this is the case, do not list a %files section for the root package, only for the -devel package. This is illustrated in the example template below.
-
-== Template
-
-....
-%global debug_package %{nil}
-
-Name:           foo
-Version:        1.2.3
-Release:        1%{?dist}
-Summary:        Does foo in D
-Group:          Development/Libraries
-License:        LGPL-2.1-or-later
-URL:            https://anywhere.com/
-Source:         https://anywhere.com/%{name}-%{version}.tar.bz2
-BuildRequires:  ldc
-Requires:       tango
-
-%description
-Foo and bar.
-
-%package devel
-Provides:       %{name}-static =  %{version}-%{release}
-Summary:        Support for developing D application
-Group:          Development/Libraries
-
-%prep
-%setup -q
-
-
-%build
-export DFLAGS="%{_d_optflags}"
-%configure
-make %{?_smp_mflags}
-
-%install
-mkdir -p %{buildroot}%{_libdir}
-mkdir -p %{buildroot}%{_d_includedir}/%{name}/
-
-make install DESTDIR=%{buildroot}
-
-install -m 0644 lib/*     %{buildroot}%{_libdir}
-install -m 0644 include/* %{buildroot}%{_d_includedir}/%{name}/
-
-%clean
-rm -rf %{buildroot}
-
-%files devel
-%doc README.txt
-%license LICENSE.txt
-%{_d_includedir}/%{name}/
-%{_libdir}/*.a
-
-%changelog
-* Wed Aug 25 2010 John Doe <jdoe@anywhere.com> 1.2.3-1
-- initial package
-....
diff --git a/guidelines/modules/ROOT/pages/Debuginfo.adoc b/guidelines/modules/ROOT/pages/Debuginfo.adoc
deleted file mode 100644
index 3d706a5..0000000
--- a/guidelines/modules/ROOT/pages/Debuginfo.adoc
+++ /dev/null
@@ -1,47 +0,0 @@
-= Debuginfo packages
-
-This page contains information about debuginfo packages and common pitfalls about them for packagers. For usage information and an explanation why debuginfo packages are important, see https://fedoraproject.org/wiki/StackTraces[StackTraces].
-
-== Checking your debuginfo package for usefulness
-
-A useful debuginfo package contains stripped symbols from ELF binaries (`+*.debug+` in `+/usr/lib/debug+`) as well as the source code related to them (in `+/usr/src/debug+`). The script that generates the packages is `+/usr/lib/rpm/find-debuginfo.sh+`, read it through to get a basic understanding of how they're generated. If your debuginfo package doesn't contain any files, or is missing the sources or the size of the `+*.debug+` files in it is unexpectedly small (typically `+*.debug+` are larger than the corresponding binary it was stripped from), it's likely that there's a flaw in your package. That's not always the case though, read on.
-
-=== Useless or incomplete debuginfo packages due to packaging issues
-
-Useless or incomplete debuginfo packages are often a result of packaging flaws. Typical flaws that often manifest themselves as debuginfo packages containing no files:
-
-* The specfile or the package's build routines explicitly strip symbols out of the binaries. Look for invocations of `+strip+`, `+install -s+`, `+ld -s+`, or `+gcc -s+` etc and get rid of them (or the `+-s+` flags). The method how to do that varies, some examples cases include patching, using `+%configure+` or a `+make+` target that prevents the strip from happening, and/or overriding a strip command like for example `+make install STRIP=/bin/true+`
-* The package is not marked as `+noarch+`, but does not contain any architecture dependent things (native binaries, architecture dependent paths etc). True `+noarch+` packages contain nothing rpmbuild could strip from them, so it's expected that they're empty if `+BuildArch: noarch+` is missing. If that's the case, make the package `+noarch+`.
-* `+find-debuginfo.sh+` processes only files that are executable when it's run; for practical purposes one can assume that happens under the hood after the `+%install+` section. Make sure that all ELF binaries (executables, shared libraries, DSO's) are executable at end of `+%install+`.
-* `+find-debuginfo.sh+` does not process setuid or setgid binaries. There's a https://bugzilla.redhat.com/117858[bug filed against rpmbuild] about that, but until it is fixed in the distros your package is targeted at, make sure that all your binaries do _not_ have the setuid/setgid bits at end of `+%install+`, and restore them in the `+%files+` section using `+%attr(...) /path/to/file+`
-
-Flaws that manifest themselves as unexpectedly small `+*.debug+` in the debuginfo package and/or source files missing:
-
-* The package was built without passing `+-g+` to `+gcc+` or `+g+++`. Without `+-g+`, no or insufficient information for debuginfo packages is generated, make sure that it is being used.
-* Note that the default `+CFLAGS+` and `+CXXFLAGS+` of the distro already contain `+-g+`, so if those flags are being honored, it should be already in use. If not, suboptimal debuginfo packages are not the only problem; the package is probably also compiled without the security enhancing options of recent compiler versions. Make sure that `+$RPM_OPT_FLAGS+` is being honored and used.
-* `+strip -g+` was used on the binaries; see above for possible remedies.
-
-=== Useless or incomplete debuginfo packages due to other reasons
-
-Empty debuginfo packages may also be generated in situations where there are no obvious packaging flaws present. Sometimes these are because of limitations of `+find-debuginfo.sh+`, sometimes not. Some usual cases:
-
-* Packages whose only architecture dependent binary part is a static library or many of them
-* R and Mono packages *TODO: people knowledgeable of R and/or Mono, verify these*
-
-If you wish to disable generation of the useless debuginfo package while waiting for improvements to `+find-debuginfo.sh+` or if it's unlikely that it could be enhanced to produce a good debuginfo for your package (for example no architecture dependent files, but package is not noarch because of the installation paths it uses), use `+%global debug_package %{nil}+` in the specfile, and be sure to add a comment next to it explaining why it was done.
-
-== Missing debuginfo packages
-
-It is normal for noarch package builds to not produce a debuginfo package. If it's missing in other cases (where it has not been explicitly disabled), something's wrong. One such case is a https://bugzilla.redhat.com/192422[missing %build section] with some rpmbuild versions.
-
-== Don't obsolete debuginfo packages
-
-In case there is removed subpackage or the subpackage is changed from arch to noarch, the associated -debuginfo package might be left behind. This might be issue, when `+fedora-debuginfo+` repository is enabled during system upgrade. Nevertheless, because the debuginfo packages has no dependencies, they are parallel installable and useful for coredump analysis, don't obsolete them anywhere.
-
-== Resources
-
-* debuginfo package listings for Fedora, sorted by size. Most debuginfo packages roughly up to 20kB in size are candidates that should be examined - however significantly larger -debuginfo packages may suffer from the same problems too, esp. in the "missing -g" case.
-** Note that due to the split repository, each directory must be examined separately.
-** https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/debug/tree/Packages/a/?C=S;O=A
-* https://fedoraproject.org/wiki/StackTraces[StackTraces]
-* rpmlint >= 0.77
diff --git a/guidelines/modules/ROOT/pages/DefaultServices.adoc b/guidelines/modules/ROOT/pages/DefaultServices.adoc
deleted file mode 100644
index 2e360c0..0000000
--- a/guidelines/modules/ROOT/pages/DefaultServices.adoc
+++ /dev/null
@@ -1,67 +0,0 @@
-= Default Services
-
-== What is a Service?
-
-For the purposes of this document, a "service" is defined as one or more of:
-
-* A daemon or process started using a https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd service unit].
-* A daemon or process that is invoked by socket activation, either by using a https://www.freedesktop.org/software/systemd/man/systemd.socket.html[systemd socket unit], https://standards.freedesktop.org/desktop-entry-spec/1.1/ar01s07.html[D-BUS activation] or similar behavior.
-* A daemon or process that is invoked by hardware activation (i.e. started via a udev rule).
-* A https://www.freedesktop.org/software/systemd/man/systemd.timer.html[systemd timer unit] that runs periodically.
-
-Note that this includes processes which are not persistent. If something started by a systemd service unit runs for a short period of time and then exits, it is still a service. An example would be `+iptables+`.
-This also includes services in the user session (i.e. started per-user by the `systemd --user` manager).
-
-== Enabling Services by Default
-
-Only services that meet all criteria below MAY be enabled by default on package installation.
-
-=== Must not alter other services
-
-Installation of the package providing the unit auto-started by this preset MUST NOT change the behavior of any other service running (or potentially running) on the system.
-
-=== Must not require manual configuration to function
-
-The service MUST NOT require configuration before it starts properly. If the end-user/administrator must make some specific configuration change before the service is able to start without error then it MUST NOT be enabled by default.
-
-=== Must not fail under normal operating conditions
-
-The service MUST NOT, under normal operating conditions, exit with an error causing systemd to mark the unit as failed. A service which is started by default is permitted to fail under exceptional conditions. For example, a service could start when appropriate hardware is present, but would still be allowed to fail if that hardware is somehow malfunctioning. Or a service could fail to start with an error if a configuration file has been locally modified to be syntactically incorrect.
-
-=== Must not listen for outside connections
-
-The service MUST NOT listen on a network socket for connections originating on a separate physical or virtual machine.
-
-D-BUS services and hardware-activated services generally meet this requirement.
-
-== Hardware Support Services
-
-Some hardware requires some additional service to be started in order to be useful. This may come in the form of a non-persistent setup process or in the form of a continuously-running service. If the service can be hardware activated to only start when the relevant hardware is present and do nothing when not present, and otherwise it meets the above requirements, then it SHOULD be enabled by default upon package installation.
-
-If the service cannot be hardware activated, but it is possible to configure it such that it will exit without error and without marking the service as "failed" according to systemd, then it SHOULD be enabled by default upon package installation. This clean exit may be accomplished through https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionArchitecture=[systemd conditionals], by having the service (or a wrapper script) perform hardware detection and exit without indicating an error, or via other similar means.
-
-== Approved Exceptions
-
-Some services which are permitted to be enabled by default as specific exceptions. Services that should be enabled by default throughout all of Fedora must be approved by https://pagure.io/fesco[FESCo]. Services that should be enabled or disabled by default only on one or more of the Fedora Editions must be approved by those Editions' https://fedoraproject.org/wiki/Fedora.next#Working_groups[Working Groups].
-
-Example:
-
-* FESCo approves openssh-server to run by default on Fedora in general.
-* Workstation WG approves openssh-server to be disabled by default on the Workstation Edition.
-
-== Current list of enabled/disabled services
-
-* https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/90-default.preset[Fedora general]
-* https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/90-default-user.preset[Fedora general (per-user)]
-* https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/80-server.preset[Fedora Server]
-* https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/81-desktop.preset[Fedora desktop (Workstation and KDE)]
-* https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/80-workstation.preset[Fedora Workstation]
-
-== How to enable a service by default
-
-Unit files must correspond to the Fedora Packaging xref:Scriptlets.adoc#_systemd[Guidelines]. Services are enabled or disabled by default through https://www.freedesktop.org/software/systemd/man/systemd.preset.html[systemd preset files]. Preset files can be overridden by a local administrator, but a set of defaults are provided by Fedora.
-
-If the service should be enabled by default, it must be added to one of the distribution presets files (see above).
-
-For services which meet one of the conditions listed above, a ticket should be filed in
-https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-systemd-request[bugzilla]. If the preset should be changed for versions other than rawhide, indicate that in the ticket.
diff --git a/guidelines/modules/ROOT/pages/Directory_Replacement.adoc b/guidelines/modules/ROOT/pages/Directory_Replacement.adoc
deleted file mode 100644
index dc309fe..0000000
--- a/guidelines/modules/ROOT/pages/Directory_Replacement.adoc
+++ /dev/null
@@ -1,108 +0,0 @@
-= Replacing a symlink with a directory or a directory with any type of file
-
-Due to a known limitation with RPM,
-it is not possible to replace a directory
-with any kind of file or symlink,
-nor is it possible to replace a symlink
-to a directory with a directory
-without RPM producing file conflict errors
-while trying to install the package.
-For more information on the issues involved, refer to
-https://bugzilla.redhat.com/show_bug.cgi?id=447156[bug 447156]
-and https://bugzilla.redhat.com/show_bug.cgi?id=646523[bug 646523].
-
-== Try to avoid the problem in the first place
-
-While it's obviously not possible to foresee all the cases
-where the need might arise,
-when the need *_is_* foreseeable,
-such as with bundled libraries,
-it is better to use a symlink from the beginning,
-as the symlink target can be changed more easily.
-For instance,
-if you have a bundled `libfoo` library
-inside the package's directory structure,
-place it in, for example, a `libfoo.bundled` directory
-and make libfoo a symlink to that.
-When the bundling is eventually removed,
-you just need to drop the directory
-and change the symlink to point
-to the corresponding system library directory,
-without resorting to the scriptlets described below.
-
-== Working around it with scriptlets
-
-To work around this problem,
-you must include a
-xref:Scriptlets.adoc#pretrans[%pretrans scriptlet]
-that manually performs the conversion
-prior to RPM attempting to install the package.
-
-Note that '+%pretrans+' scriptlets MUST be written in Lua
-and thus use `+-p <lua>+`
-in order to function during initial system installation
-when no shell has yet been installed.
-
-Please use whichever of the two following snippets is necessary
-in packages that need this transition,
-replacing `+/path/to/dir+`
-with the path to the directory that is being converted.
-
-=== Scriptlet to replace a directory
-
-RPM cannot simply remove a directory
-when it is replaced by a file or symlink,
-since users may have added or modified files to the directory.
-To protect against accidental data loss,
-you MUST use the following scriptlet
-which renames the directory with a `+.rpmmoved+` suffix
-so that users can find the backed up directory
-if they need to after the package is upgraded.
-(It also will append an integer
-to the suffix in the rare event that directory also exists.)
-
-....
-%pretrans -p <lua>
--- Define the path to directory being replaced below.
--- DO NOT add a trailing slash at the end.
-path = "/path/to/dir"
-st = posix.stat(path)
-if st and st.type == "directory" then
-  status = os.rename(path, path .. ".rpmmoved")
-  if not status then
-    suffix = 0
-    while not status do
-      suffix = suffix + 1
-      status = os.rename(path .. ".rpmmoved", path .. ".rpmmoved." .. suffix)
-    end
-    os.rename(path, path .. ".rpmmoved")
-  end
-end
-....
-
-Additionally, you should define the `+/path/to/dir.rpmmoved+`
-directory as a `+%ghost+` entry in the `+%files+` list
-in the package's spec file,
-so that the directory is not entirely orphaned
-and can be deleted if the package is ever uninstalled
-and the directory is empty.
-
-=== Scriptlet to replace a symlink to a directory with a directory
-
-Replacing a symlink to a directory
-with a regular directory is much simpler,
-since there's no potential for accidentally removing files added externally.
-The following scriptlet checks for and removes the symlink.
-There is no need to create the directory here,
-as RPM will do so later in the transaction
-when the package is installed.
-
-....
-%pretrans -p <lua>
--- Define the path to the symlink being replaced below.
-path = "/path/to/dir"
-st = posix.stat(path)
-if st and st.type == "link" then
-  os.remove(path)
-end
-....
diff --git a/guidelines/modules/ROOT/pages/DistTag.adoc b/guidelines/modules/ROOT/pages/DistTag.adoc
deleted file mode 100644
index d4b737b..0000000
--- a/guidelines/modules/ROOT/pages/DistTag.adoc
+++ /dev/null
@@ -1,166 +0,0 @@
-include::{partialsdir}/versions.adoc[]
-
-= Dist Tag Guidelines
-
-Use of the `+%{?dist}+` tag is mandatory in Fedora.
-
-You should consider this document as an addendum to the xref:Naming.adoc[Naming Guidelines].
-
-== Purpose of the Dist Tag
-
-There are several uses for a `+%{?dist}+` tag. The original purpose was so that a single spec file could be used for multiple distribution releases. In doing this, there are cases in which BuildRequires: and Requires: will need to be different for different distribution releases. Hence, `+%{?dist}+` does double duty:
-
-* it differentiates multiple packages which would otherwise have the same `+%{name}-%{version}-%{release}+`, but very different dependencies.
-
-* it allows for a conditional check in the spec to deal with the differing dependencies.
-
-=== Do I Have To Use the Dist Tag?
-
-Yes. It is very useful in maintaining proper ordering between Fedora releases and consistency in release tags is very helpful to the automated tools which are used to perform mass rebuilds.
-
-== Using +%{?dist}+
-
-Here is the important information to know:
-
-=== Possible values for +%{dist}+
-
-When you run fedpkg commands like `+fedpkg build+`, the values for `+%{dist}+` and its helper variables are assigned according to the git branch that you are working in. You do NOT need to define these variables in your spec file. fedpkg will magically set `+%{?dist}+` for you.
-
-For reference purposes only, these are some possible values for `+%{dist}+`. Note that if `+%{dist}+` is undefined, `+%{?dist}+` simply becomes empty. Also note that Fedora releases use "fc" and not "f" in the tag for historical reasons.
-
-[cols=",",options="header",]
-|==================================================================================
-|OS |+%{?dist}+ tag
-|RHEL 7 (all variants) |`.el7`
-|RHEL 8 (all variants) |`.el8`
-|RHEL 9 (all variants) |`.el9`
-|Fedora {PREVVER} |`.fc{PREVVER}`
-|Fedora {CURRENTVER} |`.fc{CURRENTVER}`
-|Fedora {NEXTVER} |`.fc{NEXTVER}`
-|(and so on)
-|==================================================================================
-
-Development:
-
-The development branch takes the disttag of the next major unreleased version of Fedora.
-
-Note the leading period in the definition of `+%{?dist}+`. This is present so that it can easily be used in the release field.
-These definitions can be found in common/branches.
-
-Note that RHEL dist tags are only defined for EPEL packages.
-
-=== +%{?dist}+ in the Release: field
-
-The `+%{?dist}+` tag is included in the Release field as follows:
-
-....
-Release: 1%{?dist}
-....
-
-This translates into:
-
-....
-If %{dist} is defined, insert its value here. If not, do nothing.
-....
-
-So, if we have the following in a spec file:
-
-....
-Name: logjam
-Version: 1.4
-Release: 2%{?dist}
-....
-
-When this package is built in an i386 FC20 buildroot, it generates an rpm named: `+logjam-1.4-2.fc20.i386.rpm+`.
-
-Keep in mind that `+%{?dist}+` should *never* be used in the Name or Version fields, nor in %changelog entries.
-
-=== Conditionals
-
-Along with `+%{?dist}+`, there are several "helper" variables defined by the buildsystem. These variables are:
-
-`+%{rhel}+`: This variable is only defined on Red Hat Enterprise Linux builds. If defined, it is set to the release number of Red Hat Enterprise Linux present at build time.
-
-`+%{fedora}+`: This variable is only defined on Fedora builds. If defined, it is set to the release number of Fedora present at build time.
-
-`+%{rhl}+`: This variable is only defined on Red Hat Linux builds. If defined, it is set to the release number of Red Hat Linux present at build time.
-
-`+%{fc#}+`: This variable is only defined on Fedora builds. For example, on Fedora {CURRENTVER} builds, `%{fc{CURRENTVER}}` is defined to 1.
-
-`+%{el#}+`: This variable is only defined on Red Hat Enterprise Linux builds. For example, on RHEL 7 builds, `+%{el7}+` is defined to 1.
-
-All of these variables, if defined, will have a purely numeric value.
-With `+%{dist}+` and these additional variables, you can create conditionals in a spec file to handle the differences between distributions.
-
-Here are some examples of how to use these variables in conditionals:
-
-....
-%if 0%{?rhel}
-%endif
-
-%if 0%{?fedora} >= 21
-%endif
-
-%{?fedora:%global _with_xfce --with-xfce}
-
-%if 0%{?rhel}
-%if 0%{?rhl}
-%endif
-%endif
-
-%if 0%{?rhl}%{?fedora}
-%endif
-
-%{?fc20:Requires: foo}
-%{?fc21:Requires: bar}
-%{?fc22:Requires: baz}
-....
-
-Keep in mind that if you are checking for a specific family of distributions, that you need to use:
-
-....
-%if 0%{?rhel}
-....
-
-and *NOT*
-
-....
-%if %{?rhel}
-....
-
-Without the extra 0, if `+%{rhel}+` is undefined, the `+%if+` conditional will cease to exist, and the rpm will fail to build.
-
-=== Distribution-specific values
-
-Fedora 37 onwards, a few helper macros are defined to help packagers write distribution-agnostic spec files:
-
-`+%{dist_vendor}+`: The vendor of the distribution.  For Fedora, this is `+Fedora+`.
-
-`+%{dist_name}+`: The name of the distribution.  For Fedora, this is `+Fedora Linux+`.
-
-`+%{dist_home_url}+`: The URL of the homepage of the distribution. For Fedora, this is `+https://fedoraproject.org/+`
-
-`+%{dist_bug_report_url}+`: The URL for reporting bugs. For Fedora, this is `+https://bugzilla.redhat.com/+`
-
-`+%{dist_debuginfod_url}+`: The URL where the debuginfod server runs (if any).  This is used
-in elfutils.spec.  For Fedora, this is `+https://debuginfod.fedoraproject.org/+`.
-
-These values are configured via the `+fedora-release+` package.  Downstream distributions of
-Fedora are expected to provide their distribution-specific values here.
-
-=== Things that you cannot use +%{?dist}+ for
-
-* You must not override the variables for `+%{dist}+` (or any of the related variables).
-* You must not hardcode a value for `+%{dist}+` (or any of the related variables) in your spec.
-* You must not hardcode a dist tag in the spec: *BAD:* Release: 1.fc{CURRENTVER} *GOOD:* Release: 1%{?dist}
-* You cannot put any sort of "tagging" in `+%{dist}+` (or any of the related variables). `+%{dist}+` (and its related variables) exist ONLY to define the distribution that a package was built against.
-* `+%{?dist}+` must never be used in the Name or Version fields, only Release, and only as documented above.
-* `+%{fedora}+`, `+%{rhel}+`, `+%{rhl}+`, `+%{fc#}+`, `+%{el#}+` must never be used in the Name, Version, or Release fields.
-
-== Common questions
-
-Q: Why don't you just let the buildsystem (or packager) pass the value for dist to rpm, e.g. `+rpm --with dist el7+`? +
-A: Actually, we do. The Fedora buildsystem defines the values for dist when you run `+fedpkg+`.
-
-Q: Why is use of `+%{?dist}+` mandatory? +
-A: There are very few packages which didn't use it, the primary very old reason for not using it (sharing large data packages across Fedora releases) is no longer relevant because all Fedora releases are signed with a different key, and having consistent Release: tags simplifies the automated tools which may need to increment them.
diff --git a/guidelines/modules/ROOT/pages/Emacs.adoc b/guidelines/modules/ROOT/pages/Emacs.adoc
deleted file mode 100644
index 0f62fc8..0000000
--- a/guidelines/modules/ROOT/pages/Emacs.adoc
+++ /dev/null
@@ -1,247 +0,0 @@
-= Packaging of add-ons for GNU Emacs
-
-== Purpose
-
-The purpose of this document is to promote good practice in packaging add-ons for GNU Emacs, and to encourage the submission of more Emacs add-on packages to the package collection by providing easy to use spec file templates.
-
-== Important notes on these Guidelines
-
-The guidelines in the following sections make extensive use of the macros defined in `+/usr/lib/rpm/macros.d/macros.emacs+` which is installed with the `+emacs-common+` package.
-
-There are two distinct cases where consideration of these guidelines is required:
-
-1.  This case refers to the situation where a package's principal purpose is to provide extra functionality for Emacs, and the package serves no purpose without the presence of Emacs. An example of this case is the VM mail reader, as packaged in `+emacs-vm+`. Below we refer to this as *Case I*.
-2.  This case refers to the situation where a package's principal functionality does not require Emacs, but the package also includes some auxiliary Elisp files to provide support for the package in Emacs. Below we refer to this as *Case II*.
-
-== Package naming and sub-package organization
-
-=== Case I
-
-Where a package is primarily an add-on for Emacs, the main package should be called `emacs-_foo_`.
-
-=== Case II
-
-Where a package's principal functionality does not require Emacs, but the package also includes some auxiliary Elisp files to provide support for the package in Emacs, these should be included in the main package which will need to Require the `+emacs-filesystem+` package.
-More detail below.
-
-== Package contents
-
-=== Case I
-
-Files specific to GNU Emacs should be placed in the main package, `emacs-_foo_`.
-This should contain the elisp source, compiled elisp and any other files needed to use the package or sub-package with GNU Emacs.
-
-=== Case II
-
-The compiled elisp source and the elisp source files should be packaged as part of the main package, and not split out into separate packages.
-
-== File locations
-
-File locations for GNU Emacs add-on (sub-)packages:
-
-* All elisp and related files for the package should be installed in the directory `+%{_emacs_sitelispdir}/foo+`.
-* If the package requires a startup file this should be called `_foo_-init.el` and be placed in `+%{_emacs_sitestartdir}+`.
-
-== Package Requires
-
-=== Case I
-
-Package Requires for GNU Emacs add-on (sub-)packages:
-
-* Where relevant `emacs-_foo_` must have `Requires: emacs-common-_foo_ = +%{version}-%{release}+`
-* `emacs-_foo_` must have `+Requires: emacs(bin)%{?_emacs_version: >= %{_emacs_version}}+`
-
-=== Case II
-
-If the package has auxillary files for use with GNU Emacs, the package must have `+Requires: emacs-filesystem >= %{_emacs_version}+`
-
-== Package BuildRequires
-
-Package BuildRequires for GNU Emacs add-on packages:
-
-* In general it should suffice to have `+BuildRequires: emacs-nw+`
-
-== Manual byte compilation
-
-Usually package Elisp compilation is handled via a make file shipped with the package, but on some occasions it may be necessary to add commands to the `+%build+` section of the spec file to byte compile files.
-In that case, use `+%{_emacs_bytecompile} file.el+`
-
-It is a requirement that all Elisp files are byte compiled and packaged, unless there is a good reason not to, in which case this should be documented with a comment in the spec file.
-
-== Use of BuildArch: noarch
-
-If an add-on package requires only byte compilation of elisp then `+BuildArch: noarch+` should be used. This is highly unlikely to ever apply to Case II.
-
-== Example spec file templates
-
-=== Template for an add-on package for GNU Emacs (Case I)
-
-This is a template for a package for GNU Emacs.
-The main package is called `emacs-_foo_` and contains all files needed to run package foo with GNU Emacs.
-This includes both compiled and source elisp files.
-
-....
-%global pkg foo
-%global pkgname Foo
-
-Name:           emacs-%{pkg}
-Version:
-Release:        %autorelease
-Summary:
-
-Group:
-License:
-URL:
-Source0:
-
-BuildArch:      noarch
-BuildRequires:  emacs-nw
-Requires:       emacs(bin)%{?_emacs_version: >= %{_emacs_version}}
-
-%description
-%{pkgname} is an add-on package for GNU Emacs. It does wonderful things...
-
-
-%prep
-%autosetup -n %{pkg}-%{version}
-
-%build
-
-
-%install
-
-
-%post
-
-
-%preun
-
-
-%files
-%doc
-%{_emacs_sitelispdir}/%{pkg}
-%{_emacs_sitestartdir}/*.el
-
-
-%changelog
-%autochangelog
-....
-
-=== Template for a package which contains auxiliary GNU Emacs files (Case II)
-
-This is a skeleton of a package which also includes support files for GNU Emacs
-
-....
-Name:           foo
-Version:
-Release:        %autorelease
-Summary:
-
-Group:
-License:
-URL:
-Source0:
-
-BuildRequires:  emacs-nw
-Requires:       emacs-filesystem%{?_emacs_version: >= %{_emacs_version}}
-
-%description
-Foo is a package which contains auxiliary Emacs support files.
-
-
-%prep
-%autosetup
-
-%build
-
-
-%install
-
-
-%post
-
-
-%preun
-
-
-%files
-%doc
-%{_emacs_sitelispdir}/foo
-%{_emacs_sitestartdir}/*.el
-
-%changelog
-%autochangelog
-....
-
-== Principles behind the guidelines
-
-=== Location of installed files
-
-Files for add-on package foo should be placed in `+%{_emacs_sitelispdir}/foo+` which evaluates to `/usr/share/emacs/site-lisp/_foo_`.
-
-Usually an add-on package will require a startup file, and this should be called `_foo_-init.el` and be placed in `+%{_emacs_sitestartdir}+` which evaluates to `+/usr/share/emacs/site-lisp/site-start.d/+`.
-
-=== Packaging of source elisp files
-
-Typically, an Emacs add-on package will be compiled from source elisp files.
-The resulting compiled elisp files will then be included in the relevant `emacs-_foo_` package.
-It is important to also include the source elisp files for several reasons.
-For example when debugging a problem with an Emacs package, the Elisp debugger can look up the relevant code or symbol definition in the source lisp file if present.
-Also, it's sometimes helpful to jump to a variable description string from the Emacs help system.
-
-=== BuildArch for Emacs add-on packages
-
-You should set `+BuildArch: noarch+` for add-on packages which only compile elisp files during building.
-
-If the package building process also compiles programs in other languages, you may need to not set `+BuildArch+`.
-
-=== Requires for GNU Emacs
-
-Add-on packages should have appropriate Requires entries for the flavor of Emacs they are targeted at.
-GNU Emacs is available in multiple packages - some details of these packages follow.
-
-1. The `+emacs+` package is built with pure GTK support to allow the user to run Emacs in a windowed environment.
-2. The `+emacs-gtk+x11+` package is built with X11 support via the GTK toolkit to allow the user to run Emacs in a windowed environment.
-3. The `+emacs-lucid+` package is built with X11 support via the Lucid toolkit to allow the user to run Emacs in a windowed environment.
-4. The `+emacs-nw+` package is built without GUI support.  It is suitable for running in a terminal.
-
-Note:
-
-* The `+emacs+`, `+emacs-gtk+x11+`, `+emacs-lucid+`, and `+emacs-nw+` packages all have Requires: emacs-common.
-* The emacs, `+emacs-gtk+x11+`, `+emacs-lucid+`, and `+emacs-nw+` packages all have a virtual Provides: `+emacs(bin)+`.
-
-Assuming your add-on package will work in both a windowed and a console Emacs session, it is wrong to have `+Requires: emacs+` as that would pull in a dependency on GTK even if the console variant of Emacs is installed.
-Rather you should use Requires: `+emacs(bin)+` for GNU Emacs add-on packages.
-
-If the package ONLY works with GTK support built into Emacs, then the package should have `+Requires: emacs+`.
-This is very uncommon.
-
-==== Why we need versioned Requires
-
-Many elisp packages aim for backwards source level compatibility by checking whether some features exist in the Emacs in use when the package is being run or byte-compiled.
-If yes, they use what's available.
-If no, they provide their own versions of missing functions, macros etc.
-This propagates into `+*.elc+` during byte compilation, and quite a few functions do get added between upstream Emacs releases.
-
-So let's say I byte-compile a package into `+*.elc+` with Emacs 29.3.
-Elisp package `_quux_` checks if the `_foo-bar_` function is available in the Emacs being used to byte-compile it.
-Yes, it is, so the internal backwards compat version of `_foo-bar_` included in `_quux_` does not end up in the `+*.elc+`.
-Now, let's assume `_foo-bar_` was added in Emacs 29.3 and didn't exist in 29.2 and we're trying to run the `+*.elc+` with 29.2 -> boom, `_foo-bar_` is not available.
-Note: this wouldn't happen if only `+*.el+` were shipped - `+*.elc+` are the potential and likely problem.
-Requiring >= version of the Emacs used to byte-compile the `+*.elc+` is not the only solution (nor enough for all corner cases), but is the best one we currently have available.
-
-The main package and subpackages will need to have appropriately versioned Requires to ensure that a recent enough version of Emacs is installed.
-Emacs byte compiled lisp is usually forward compatible with later Emacs versions, but is frequently not compatible with earlier versions of Emacs.
-
-==== Determining the Required Emacs version at package build time
-
-It is recommended to derive greater-than-or-equal-to valued versioned dependencies from the version of Emacs used to byte-compile the package at package build time.
-The `+emacs-common+` package includes `+/usr/lib/rpm/macros.d/macros.emacs+` which defines a `+%{_emacs_version}+` macro containing the version of Emacs installed.
-
-=== Other packages containing Emacsen add-ons (Case II)
-
-It is often the case that a software package, while not being primarily an Emacs add-on package, will contain components for Emacs.
-For example, the Gnuplot program contains some elisp files for editing Gnuplot input files in GNU Emacs and running Gnuplot from GNU Emacs.
-In this case, we want to enable the Emacs support IF Emacs is installed, but we don't want to mandate the installation of Emacs on installation of this package since Emacs is not required for providing the core functionality of the package.
-To enable this, the `+emacs-filesystem+` sub-package was created which owns the `+/usr/share/emacs/site-lisp+` directory.
-A package can then Require the `+emacs-filesystem+` package in order to install its Elisp files without pulling in Emacs and its dependency chain.
diff --git a/guidelines/modules/ROOT/pages/EnvironmentModules.adoc b/guidelines/modules/ROOT/pages/EnvironmentModules.adoc
deleted file mode 100644
index c348263..0000000
--- a/guidelines/modules/ROOT/pages/EnvironmentModules.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-= Environment Modules
-
-== Introduction
-
-When one has multiple programs serving the same purpose (for instance SMTP servers such as sendmail, exim and postfix; or print servers such as lprng and cups), it is usual to wrap these using alternatives. Alternatives provides a clean way to have many types of software serving the same purpose installed at the same time and have the commands such as `+mail+` and `+lpr+` point to the wanted versions.
-
-However, when there are multiple variants that each serve the needs of some user and thus must be available simultaneously by users, the alternatives system simply isn't enough since it is system-wide. This has been reality on supercomputers and clusters for eons, and multiple implementations of a solution has been developed: http://modules.sourceforge.net/[environment modules] and https://www.tacc.utexas.edu/tacc-projects/lmod[Lmod]. Fedora currently makes use of this primarily for handling switching between different MPI implementations.
-
-Environment modules are also useful in situations where a package wants to install binaries that use common names and might conflict file in or otherwise pollute /usr/bin. Use must then load an environment module before being able to make use of those programs.
-
-== Using environment modules
-
-To see what modules are available, run `+$ module avail+`.
-To load a module run e.g. `+$ module load mpi/openmpi-x86_64+`.
-To unload a module, run e.g. `+$module unload mpi/openmpi-x86_64+`.
-
-The upstream documentation for the module command is available https://modules.readthedocs.io/en/stable/module.html[here] or with `+man module+`.
-
-== Creating environment modules
-
-To install an environment module, place a module file into `+%{_modulesdir}+`, which should evaluate to `+/usr/share/modulefiles+`. This macro is available in Fedora and EPEL 7+. The directory `+/usr/share/Modules/modulefiles+` is to be used only for internal modules of environment-modules. `+/etc/modulefiles+` is available to local system administrator use.
-
-The module files are plain text with optional tcl syntax, for instance an environment module for 64-bit OpenMPI `+mpi/openmpi-x86_64+`:
-
-....
-#%Module 1.0
-#
-#  OpenMPI module for use with 'environment-modules' package:
-#
-conflict                mpi
-prepend-path            PATH            /usr/lib64/openmpi/bin
-prepend-path            LD_LIBRARY_PATH /usr/lib64/openmpi/lib
-prepend-path            PYTHONPATH      /usr/lib64/python2.7/site-packages/openmpi
-prepend-path            MANPATH         /usr/share/man/openmpi-x86_64
-setenv                  MPI_BIN         /usr/lib64/openmpi/bin
-setenv                  MPI_SYSCONFIG   /etc/openmpi-x86_64
-setenv                  MPI_FORTRAN_MOD_DIR     /usr/lib64/gfortran/modules/openmpi-x86_64
-setenv                  MPI_INCLUDE     /usr/include/openmpi-x86_64
-setenv                  MPI_LIB         /usr/lib64/openmpi/lib
-setenv                  MPI_MAN         /usr/share/man/openmpi-x86_64
-setenv                  MPI_PYTHON_SITEARCH     /usr/lib64/python2.7/site-packages/openmpi
-setenv                  MPI_COMPILER    openmpi-x86_64
-setenv                  MPI_SUFFIX      _openmpi
-setenv                  MPI_HOME        /usr/lib64/openmpi
-....
-
-The module file begins with the magic cookie `+#%Module +`, where is the version of the module file used. The current version is 1.0.
-
-The above commands prepends the path with the bindir of the 64-bit OpenMPI (compiled with GCC) and adds the relevant library path. Then it sets various environment variables.
-
-It is also possible to set `+CFLAGS+` and `+LDFLAGS+` with the above manner, but in the case of MPI compilers it is not necessary since the compilers are invoked with the `+mpicc+`, `+mpicxx+`, `+mpif77+` and `+mpif90+` wrappers that already contain the necessary include and library paths. Also, in the case of development packages an override of `+CFLAGS+` and/or `+LDFLAGS+` is not sane, as it may cause trouble in building RPMs as it overrides `+%{optflags}+`.
-
-The upstream documentation for module files is available https://modules.readthedocs.io/en/stable/modulefile.html[here] or with `+man modulefile+`.
-
-== Switching between module implementations
-
-Switching between the environment-modules and Lmod implementations is done via alternatives. The shell init scripts /etc/profile.d/modules.\{csh,sh} are links to /etc/alternatives/modules.\{csh.sh} and can be manipulated with the alternatives command.
-
-== Lmod
-
-https://www.tacc.utexas.edu/tacc-projects/lmod[Lmod] is an environment modules implementation written in Lua, and can make use of module files written in Lua as well as Tcl. Such files have a ".lua" extensions. However, such files *must not* be installed /usr/share/modulefiles so as to not cause issues when the environment-modules package is in use. Instead install into %\{_datadir}/lmod/lmod/modulefiles/Core.
diff --git a/guidelines/modules/ROOT/pages/FontsPolicy.adoc b/guidelines/modules/ROOT/pages/FontsPolicy.adoc
deleted file mode 100644
index 9688c1e..0000000
--- a/guidelines/modules/ROOT/pages/FontsPolicy.adoc
+++ /dev/null
@@ -1,1068 +0,0 @@
-= Fonts
-
-== Foreword
-
-The bulk of Fedora software relies on OpenType compliance and was tested against compliant fonts.
-
-Unfortunately, most font makers feel the OpenType specification is a document written by “software people” for “software people”.
-They spurn its recommendations.
-They can not be relied upon to release fonts in a software-friendly state,
-nor to fix the resulting problems, nor to provide useful advice.
-
-To enable the packaging of fonts by non experts, <<Checklist>> provides a list of sanity rules.
-Most are short unambiguous one liners, easy to understand and apply.
-Do read this list, even if it feels long.
-Unless your upstream is a model of discipline, you WILL need it.
-Avoid <<Exceptions>> if you do not feel ambitious – here be dragons.
-
-Once you sorted what to package using the checklist, the rpm-specific part of fonts packaging is simple:
-
-* take our spec templates,
-* fill in the blanks with descriptions and the file lists resulting from the sorting.
-
-Fedora automation will do the rest.
-
-<<Tooling>> provides in-depth documentation of those templates, and other operational tips.
-The operational tips are useful.
-The spec templates documentation, not so much.
-The templates are commented and will usually be self-explanatory.
-
-Lastly, <<Rationale>> provides some help, in case a third party attempts to confuse you.
-A lot of upstreams are dead set against applying OpenType recommendations.
-They will provide elaborate argumentation, on why the common rule does not apply to them.
-
-== Checklist
-
-=== Legal
-
-* [x] Font files MUST comply with our https://docs.fedoraproject.org/en-US/legal/license-approval/#_licenses_allowed_for_fonts.
-* [x] Trademark uses MUST be authorized by their owners,
-** trademarks may occur in font naming or font content (logos…).
-* [x] Registered names or trademarks MUST NOT prevent downstream modifications,
-** requiring a rename on significant modification is acceptable.
-
-=== Packaging unit: an ideal font family
-
-Because fonts upstreams are, on average, extremely messy,
-a large part of packaging fonts involves sorting files and fixing font file metadata to produce the consistent and
-reliable font catalog expected by applications and users.
-
-[IMPORTANT]
-====
-.Font family
-A **font family** is composed of *font files, that share a single design, and differ ONLY in*:
-[horizontal]
-Weight:: Bold, Black…
-Width∕Stretch:: Narrow, Condensed, Expanded…
-Slope/Slant:: Italic, Oblique
-Optical sizing:: Caption…
-
-Those parameters correspond to the
-https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg#registered-axis-tags[default axes]
-of OpenType variable fonts.
-====
-
-* [x] Packagers MUST apply the definition provided in this section to determine font family boundaries,
-** it takes precedence over application support concerns, over upstream and packager habits and practices.
-
-See also the <<Fontconfig>> section.
-
-=== Font file formats
-
-[NOTE]
-====
-.OpenType: one standard, five formats
-https://en.wikipedia.org/wiki/OpenType[OpenType] uses an _SFNT_ container around bitmaps (`+*.otb+`) and
-outlines in _TT_ (`+*.ttf+`) or _CFF_ (`+*.otf+`) formats.
-Multiple fonts can be consolidated in a single collection (`+*.ttc+` or `+*.otc+`).
-====
-
-* [x] Other font formats MUST be converted to OpenType,
-** except for fonts, intended to be used in the console (NOT a terminal emulator): see <<Bitmap console fonts>>.
-* [x] Font packages MUST NOT contain font files in non OpenType formats.
-
-[NOTE]
-====
-.Font packages
-A *font package*, is an installation (RPM) package, containing OpenType font files.
-It MAY be produced by a source (SRPM) package, that also produces other (font or non-font) packages.
-Other kinds of font packages are out of scope for this document.
-====
-
-* [x] A font family MUST NOT be packaged in multiple or mixed OpenType formats,
-** except for variable font data,
-** except when mixing is required, to achieve full symbol (glyph) coverage,
-** except as an application workaround; see <<Packaging a font family in multiple OpenType formats; application support>>.
-* [x] Both variable and non-variable OpenType font files, SHOULD be packaged, for a given font family.
-* [x] OpenType format mixing SHOULD be justified in a comment within the `spec` file.
-* [x] OpenType collection formats SHOULD be avoided.
-
-=== Fontconfig
-
-* [x] Font packages SHOULD include the fontconfig files,
-that define the selection and substitution rules applying to their font files,
-** written by the packager if upstream does not provide them.
-* [x] Fontconfig rules MUST rewrite `family` and `style` when they are not compliant with
-https://docs.microsoft.com/en-us/typography/opentype/spec/name#name-ids[OpenType WWS] rules:
-** `family` MUST NOT contain _Weight_, _Width_ or _Slope_ attributes (ideal WWS family name, Name ID 21),
-** `style` MUST contain only _Weight_, _Width_ or _Slope_ attributes (ideal WWS subfamily name, Name ID 22),
-**  Name ID 21 & 22 fields may exist or not in the packaged font files, and may be correct or not. The packager MUST set the correct value at the fontconfig level if the value fontconfig extracts from font files is incorrect.
-* [x] Fontconfig rules MUST rewrite `family` to remove format attributes when they exist,
-** for example: `OT`, `TT`, `Variable`, `Graphite`, `G`, etc,
-** except when <<Packaging a font family in multiple OpenType formats; application support>>;
-in that case the removal MUST only be done for the font package providing the default format.
-* [x] Fontconfig rules MUST rewrite `family` to remove coverage attributes when they exist,
-** for example: `Math`, `Emoji`, `Color Emoji`, `Hebrew`, `Arabic`, `Thai`, `LGC`, etc,
-** except when several font files provide the same coverage,
-requiring a qualifier to distinguish between them;
-in that case the removal MUST be done for the default file,
-and other files MUST be treated as parts of separate font families.
-* [x] Fontconfig rules MUST rewrite `fullname` to `<family> <style>` if it has a different value,
-** either natively or as a result of previous rewrites,
-** except for the default style, usually `Regular`, for which `fullname` = `<family>`.
-* [x] Fontconfig rules MUST rewrite `fontversion` when several font files provide the same `fullname` and have overlapping coverage,
-** either natively or as a result of previous rewrites,
-** fontconfig will merge the result, higher `fontversion` taking precedence over lower,
-** therefore, `fontversion` MUST be set by the packager, to define the correct ordering.
-* [x] Fontconfig rules SHOULD define the generic family, a font contributes to,
-** a single generic family: the packager MUST choose,
-** using the correct priority: lower takes precedence over higher.
-* [x] Fontconfig rules SHOULD list what other font families, the provided font family can substitute for.
-** typically, anterior namings, known forks, alternatives with the same font metrics…
-** also, the reused fonts families when <<Assembling different-family font packages: partial designs>>.
-* [x] Fontconfig rules SHOULD define the font families, that can be used to complete the font family,
-** in all cases: at least the generic family and the substitutes defined before,
-** generic family last in completion order.
-* [x] Packagers SHOULD attempt upstreaming those fixes,
-** make the font naming correct in the upstream font files,
-** contribute the other fontconfig rules upstream, so they are distributed with the font files.
-* [x] Packagers SHOULD consult the fontconfig
-https://src.fedoraproject.org/rpms/fontconfig/[maintainer] and
-https://lists.freedesktop.org/mailman/listinfo/fontconfig[mailing list] when in doubt,
-** to get guidance and identify real-world tricky cases that call for fontconfig evolutions.
-
-See also the <<Tooling>> section for fontconfig syntax guidance.
-
-=== Source (SRPM) package break-up
-
-* [x] Separate source archives MUST be packaged in separate `spec` files,
-** except when those contain parts of the same font family and upstream coordinates their release.
-* [x] `spec` files SHOULD track a single font family,
-** except when distinct font families are only released upstream in a common archive.
-* [x] Packagers SHOULD ask upstream to split unrelated font families in separate versioned source archives,
-** and package font families from their actual respective upstreams when they are bundled with other material in a third party project.
-
-=== Installation (RPM) package break-up: font packages
-
-* [x] Packagers MUST ship each font family in a single dedicated font package,
-** all the files that, after fontconfig fixing,
-*** share the same `family` value: `family` = `<common family>`
-*** or differ only in optical sizing: `family` = `<common family> <optical sizing attribute>`,
-** except when released as un-coordinated sources,
-that are easier to track in separate `spec` files,
-** except for huge families, that consume a lot of storage space;
-huge font families MAY be broken up in coverage-specific font packages,
-** see <<Assembling same-family font packages>>.
-* [x] Font packages MUST limit themsemselves to OpenType font files and their associated
-https://www.fontconfig.org/[fontconfig],
-https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Fonts.html[appstream],
-legal and documentation files,
-** for reasonable non-bulky interpretations of documentation files.
-
-See also the <<Tooling>> section.
-
-[IMPORTANT]
-====
-.Other upstream files
-
-Support for other font systems,
-for specific applications,
-non-OpenType font formats,
-bulky documentation, TEX, CSS, or JSON files…
-MUST be split in separate non-font packages,
-that SHOULD install outside `/usr/share/fonts`,
-and MUST NOT use `_<something>_-fonts` naming.
-
-For compatibility reasons,
-OpenType font files MAY be exposed outside `/usr/share/fonts`,
-with the rest of upstream files, using symbolic links.
-Those symbolic links SHOULD NOT be installed by the font package itself.
-====
-
-=== Building
-
-* [x] Packagers SHOULD build font files from sources,
-** whenever their prefered modification format is not the packaged OpenType format
-** and if the required toolchain is available as free software under Linux
-
-=== Dependencies in font packages
-
-* [x] Font packages MAY require or supplement other font packages,
-when they contain the same font family,
-** as defined in <<Assembling same-family font packages>>.
-* [x] Font packages SHOULD recommend other font packages,
-when they contain a reused font family,
-** as defined in <<Assembling different-family font packages: partial designs>>.
-* [x] Font packages SHOULD suggest other font packages,
-when they contain a better version of the same font family,
-** better: more complete coverage,
-later enhanced fork,
-canonical version of the design…
-* [x] Font packages MAY suggest or enhance font packages,
-containing other font families,
-** this should be used sparsely,
-to avoid imposing packager preferences on users.
-* [x] Font packages SHOULD depend on the basic font support package set,
-defined in the font packaging templates and macros.
-* [x] Except for the preceding,
-font packages MUST NOT depend,
-in any form,
-on any other package.
-
-=== Dependencies to font packages in other packages
-
-* [x] Non-font packages MAY suggest or recommend font packages,
-** the weakest `Suggests` form is preferred over `Recommends`,
-except in presence of strong pre-existing user habits.
-* [x] Non-font packages SHOULD use the `font()` namespace to depend on font packages.
-* [x] Non-font packages SHOULD NOT require specific font packages,
-and leave font selection to end-users,
-** except when the packaged software actually relies on those specific font packages,
-** except for convenience font metapackages,
-as defined in <<Assembling different-family font packages: font metapackages>>.
-* [x] Non-font packages SHOULD require `font(:lang=en)` when they fail in the absence of system fonts,
-** hardcoding specific font families is not future-proof.
-* [x] Non-font packages MAY require font packages by name,
-when relying on specific on-disk font file paths,
-** ie when software is not `fontconfig`-aware,
-** however, there is no obligation for font packagers to keep those paths stable between releases.
-Font file formats are flexible,
-making any on-disk file layout temporary.
-Converting applications to fontconfig use is best.
-
-=== Assembling different-family font packages: partial designs
-
-[NOTE]
-====
-.Font reuse and font extension
-
-Because font creation is hard work, font designers will often publish partial new designs:
-
-* they will copy part of an existing design, then add to it;
-this is common practice when designing a non-latin-oriented font family – the latin core is taken from an existing family,
-* or they will publish their additions as a separate font family,
-documenting it should be used with the original family;
-this is common practice when publishing alternate designs for part of a font.
-====
-
-When packaging such a partial design:
-
-* [x] The font package containing the new font family SHOULD recommend the package containing the original font family,
-** only the core package of the original font family in case of <<Assembling same-family font packages>>.
-* [x] Re-use recommendations SHOULD use the `font()` namespace.
-
-=== Assembling different-family font packages: font metapackages
-
-* [x] Packagers MAY provide convenience font metapackages,
-** for example, when an upstream releases a collection of font families, intended to be used together,
-** a common case is matched _serif_, _sans-serif_ and _monospaced_ font families.
-* [x] Font metapackages MUST NOT use the same naming conventions as actual font packages,
-** they MUST NOT be named `_<something>_-fonts`,
-** they MAY be named `_<something>_-fonts-all`.
-* [x] Font metapackages MUST require, recommend or suggest separate font packages, that conform to this document,
-* [x] Font metapackages SHOULD use the `font()` namespace to require, recommend or suggest actual font packages,
-** see <<Dependencies to font packages in other packages>>.
-* [x] Font metapackages SHOULD NOT contain any other file, except for documentation.
-
-== Exceptions
-
-=== Bitmap console fonts
-
-* [x] Bitmap console fonts MAY be packaged in a legacy font format, understood by https://kbd-project.org/[kbd].
-* [x] Bitmap console fonts MUST be installed in `/lib/kbd/consolefonts/` not `/usr/share/fonts`.
-* [x] Bitmap console font packages SHOULD be named `_<something>_-fonts-console` not `_<something>_-fonts`.
-
-[NOTE]
-====
-.Console fonts
-As long as https://kbd-project.org/[kbd] and
-https://www.freedesktop.org/software/systemd/man/vconsole.conf.html[systemd-vconsole]
-can not use the same file formats as the rest of the system,
-bitmap console fonts are effectively private kbd resources.
-They will be ignored in the rest of this document.
-It does not apply to them.
-====
-
-=== Assembling same-family font packages
-
-* [x] A font family MUST NOT be split over several font packages,
-unless one of the exceptions listed above applies.
-
-When a font family is split over a set of several font packages:
-
-* [x] Involved packagers MUST choose a core font package.
-* [x] This core package SHOULD contain the font files,
-necessary to provide a minimal scope of the font family.
-* [x] This core package MAY contain fontconfig rules,
-for all the font files composinng the font family,
-** fontconfig ignores rules that do not match installed files.
-* [x] This core package MUST be named as if it contained the whole font family.
-* [x] This core package MUST NOT require any other package in the set.
-* [x] The other packages of the set MUST require, directly or indirectly, this core package.
-* [x] The other packages of the set MUST supplement, directly or indirectly, this core package.
-* [x] The other packages of the set MUST NOT use the `font()` namespace to require or supplement other parts of the set,
-** Splitting a font family interacts badly with `font()` auto-provides.
-* [x] All the packages involved in an indirect require or supplement chain MUST be part of the set.
-
-=== Packaging a font family in multiple OpenType formats; application support
-
-* [x] Packagers MUST make a reasonable effort,
-to get applications that do not support all OpenType formats,
-fixed upstream.
-* [x] If that fails, as a last ressort,
-packagers MAY request a https://pagure.io/fesco[FESCo exemption],
-to package a limited number of font families in multiple OpenType formats.
-* [x] Packagers MUST ensure that the resulting additional font data,
-is separated in distinct font packages,
-** that the average Fedora user can install those font families in a single format,
-** that he is not left wondering,
-which package to install.
-
-== Tooling
-
-Creating font packages by hand can be extremely repetitive,
-error-prone and labor-intensive.
-Therefore, fonts packaging is heavily automated.
-It relies on numerous macros and variables to define what goes where.
-
-Those macros and variables are defined in the `fonts-rpm-macros` package.
-The `fonts-rpm-templates` package contains `spec` and `fontconfig` templates,
-corresponding to common fonts packaging needs.
-
-=== Fontconfig
-
-The `fonts-rpm-templates` package contains `fontconfig` templates,
-corresponding to common fonts packaging needs.
-
-Using fontconfig, you can help users and software make sense of broken font files.
-
-
-[NOTE]
-====
-.On brokenness and interoperability
-Fixing may imply behaviour differences, with entities that chose another mitigation strategy.
-The root cause of those differences is the upstream release of files in a broken state.
-Producing daring glyph shapes is the designer prerogative.
-That artistic license does not extend to flouting technical conventions, software relies on.
-
-Upstream should always be given the chance to fix its files.
-If it does not care about our needs, fixing downstream is second best.
-Inflicting intact breakage on our users is always worst.
-====
-
-==== Some applications
-
--  The Foo project releases `Foo Narrow Oblique`.
-Because the font maker remembers early font formats only allowed 4-style family grouping
-(https://docs.microsoft.com/en-us/typography/opentype/spec/name#name-ids[Name ID] 1 and 2),
-it declares it as `family: Foo Narrow` and `style: Oblique`.
-The fontconfig rules for `Foo Narrow Oblique` MUST rewrite it to the
-https://docs.microsoft.com/en-us/typography/opentype/spec/namesmp[recommended]
-https://docs.microsoft.com/en-us/typography/opentype/spec/name#nid21[WWS-compliant]
-`family: Foo` and `style: Narrow Oblique` (Name ID 16/17 or 21/22).
-- The Foo project releases the `Universal Foo` wide-coverage font family.
-To allow installing only part of this family,
-it splits it in `Universal Foo`,
-`Universal Foo Hebrew` and `Universal Foo Thai`.
-The fontconfig rules for `Universal Foo` MUST rewrite the `family` (and therefore `fullname`)
-for all `Universal Foo Hebrew` and `Universal Foo Thai` font files,
-so they declare `Universal Foo` instead.
-Fontconfig will present the result as a single wide-encoding family to applications,
-even if the files remain split on-disk,
-even if all of them are not installed.
-- The Foo project releases `Foo Sans`.
-The fontconfig rules for `Foo Sans` SHOULD declare any missing glyph can be taken from the `sans-serif` generic font family.
-- The GNOME project releases the `Bitstream Vera` set of font families;
-later the `DejaVu` project forks and extends those fonts.
-The fontconfig rules for `DejaVu Sans` SHOULD declare it can be substituted for `Bitstream Vera Sans`.
-- Microsoft ships Windows with the `Arial` font family.
-Due to its long and wide availability, `Arial` is now used in many documents.
-However it can not be included in Free Desktop systems for licensing reasons.
-Red Hat commissions an `Arial` substitute, `Liberation Sans`, for use on Linux.
-Google commissions another `Arial` substiture, `Arimo`, for use on ChromeOS.
-The fontconfig rules for `Liberation Sans` SHOULD declare it can be substituted for both `Arial` and `Arimo`.
-
-==== Style naming
-
-The https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass[OpenType]
-https://docs.microsoft.com/en-us/typography/opentype/spec/os2#uswidthclass[specification],
-the https://www.w3.org/TR/css-fonts-4/#font-weight-prop[CSS]
-https://www.w3.org/TR/css-fonts-4/#font-stretch-prop[specification] and the
-https://www.freedesktop.org/software/fontconfig/fontconfig-user.html[fontconfig manual]
-document the canonical mappings of style keywords.
-
-Those mappings are not absolute.
-The addition of variable capabilities enabled the creation of new keywords and axes values,
-including in non variable font files.
-
-Nevertheless, the OpenType specification requires correlating the new capabilities with the traditional keyword scale:
-
-* [x] an axis step, with a value, close to one of the specification keywords, SHOULD be named with this keyword,
-** a slight deviation from the canonical keyword value, for design reasons, is expected and accepted.
-* [x] an axis step, SHOULD NOT be named with a keyword, when its value differs greatly from the keyword canonical value,
-** font files that define new intermediary steps should also define new keywords.
-
-Additionnally:
-
-* [x] axis keywords SHOULD NOT use whitespace, due to software processing constraints,
-** `SemiCondensed` is a good keyword; `Semi Condensed` — not.
-* [x] keywords SHOULD be assembled in `width weight slant` order in style names, for historical reasons,
-** with the default `Regular` ommited except when alone.
-
-==== Checking results
-
-To verify the metadata of font files installed by a package named `$\{pkg}`:
-
-.Check command
-[source,bash]
-----
-fc-scan -f \
- "%{family[0]};%{style[0]};%{fullname[0]};%{width};%{weight};%{slant};%{fontversion};%{file}\n" \
- /usr/share/fonts/${pkg} | sort -t ';' -k1,1d -k4,4n -k5,5n -k6,6n -k2,2d -k7,7dr \
- | uniq | column --separator ';' -t
-----
-
-.Command output, before fixes
------
-include::{examplesdir}/fonts/before-fontconfig-fixes.txt[]
-…
------
-
-.Command output, once fixed
-[source,options="nowrap"]
------
-include::{examplesdir}/fonts/after-fontconfig-fixes.txt[]
-…
------
-
-=== Spec template documentation
-
-The `fonts-rpm-templates` package contains `spec` templates, corresponding to common fonts packaging needs.
-
-==== Packaging a single font family
-
-This is the simplest packaging pattern, when upstream releases:
-
-* a single font family,
-* conforming to this guideline’s definition of a font family,
-* in a single dedicated source archive,
-* without any specific difficulty.
-
-===== Macros and variables
-
-[IMPORTANT]
-====
-.Declaration ordering
-Changing the proposed line order will more often than not result in a `spec` file that still works.
-That may be tempting, since the suggested order is far from traditional.
-
-Be aware that this particular order was selected after reworking a large pool of test files,
-to maximize commonalities,
-and reduce divergence between packaging situations.
-Reordering may still work but the result will be harder to review, refactor, and copy in other `spec` files.
-====
-
-====== SRPM generic declarations
-
-This pattern starts with a block of traditional `spec` declarations:
-
-.SRPM generic declarations
-[source,rpm-spec]
-----
-Version:
-Release:
-URL:
-----
-
-====== Shared font declarations
-
-Then it declares elements,
-that will be shared by all the packaged font families.
-Here, we only process one of those, but the block will be at the same place in the other patterns.
-
-[horizontal]
-%\{foundry}:: an optional upstream identifier,
-when upstream publishes multiple font families, with consistent QA rules.
-Font families released by the same upstream will usually play well with one another.
-Marking them as such helps users choose good font package sets.
-If there is no registered foundry,
-the name or brandname of the typographer can be used instead provided it enables distinguishing the font.
-* for example, the https://fontlibrary.org/[Open Font Library] identifier is `oflb`.
-%\{fontlicense}:: the identifier of the font family license, according to our licensing rules.
-
-Those identifiers are followed by variables, containing:
-
-* lists of space-separated shell globs,
-* matching the files associated with the font family,
-* as they exist in the build root at the end of the `%build` stage.
-
-[horizontal]
-%\{fontlicenses}:: the font family legal files
-%\{fontdocs}:: the font family documentation files
-%\{fontdocsex}:: exclusions from the `%\{fontdocs}` list
-
-.Shared font declarations
-[source,rpm-spec]
-----
-%global foundry           SIL
-%global fontlicense       OFL-1.1
-%global fontlicenses      OFL.txt
-%global fontdocs          *.txt
-%global fontdocsex        %{fontlicenses}
-----
-
-====== Family-specific font declarations
-
-This is followed by a family-specific declaration block.
-
-[horizontal]
-%\{fontfamily}:: the human-friendly font family name, whitespace included, restricted to the *Basic Latin* Unicode block.
-%\{fontsummary}:: the generated font package summary. It must be less than 80 columns in length.
-
-This block contains its own shell glob lists.
-
-[horizontal]
-%\{fonts}:: the font family font files
-%\{fontconfs}:: the font family fontconfig files
-
-Followed by:
-
-[horizontal]
-%\{fontdescription}:: a multi-line description block for the generated package. Each line should be less than 80 columns in length.
-
-.Family-specific font declarations
-[source,rpm-spec]
-----
-%global fontfamily        Andika
-%global fontsummary       SIL Andika, a font family for literacy and beginning readers
-%global fonts             *.ttf
-%global fontconfs         %{SOURCE10}
-%global fontdescription   %{expand:
-Andika is a sans serif, Unicode-compliant font family designed especially for
-literacy use, taking into account the needs of beginning readers. The focus is
-on clear, easy-to-perceive letterforms that will not be readily confused with
-one another.}
-----
-
-====== Source declarations
-
-Then package sources are declared the usual way.
-
-.Source declarations
-[source,rpm-spec]
-----
-Source:
-Source10: [number]-%{fontpkgname}.conf
-----
-
-Keeping fontconfig file names in sync with the package name is a good idea.
-Take a look at the templates in `fonts-rpm-templates` for information on how to write good fontconfig files
-and choose the correct priority `[number]`.
-
-[NOTE]
-====
-.Font package names
-Font package names will be automatically computed from the previous declarations,
-and put into the `%\{fontpkgname}` variable.
-You MAY override this variable at need.
-However, needing an override usually indicates that either the upstream font naming is broken,
-or you’re trying to do something wrong.
-====
-
-====== Remainer of the spec file
-
-All those declarations are used and processed in the rest of the `spec` file by the following macros:
-
-[horizontal]
-%fontpkg:: generate font package headers
-%fontbuild:: perform font-related steps, at the end of the `%build` section
-%fontinstall:: perform font-related steps, at the end of the `%install` section
-%fontcheck:: perform font-related steps, at the end of the `%check` section
-%fontfiles:: generate font package `%file` lists
-
-.Remainer of the spec file
-[source,rpm-spec]
-----
-%fontpkg
-
-%prep
-%setup
-
-%build
-%fontbuild
-
-%install
-%fontinstall
-
-%check
-%fontcheck
-
-%fontfiles
-
-%changelog
-----
-
-===== Annotated spec template
-
-Putting it all together:
-
-.spectemplate-fonts-0-simple.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/fonts/spectemplate-fonts-0-simple.spec[]
-----
-
-==== Packaging a single font family (advanced)
-
-Sometimes, packaging a font family requires a little more work, with the associated automation.
-You may need to complete the previous pattern.
-
-===== Macros and variables
-
-====== Shared font declarations
-
-One more shell glob list:
-
-[horizontal]
-%\{fontlicensesex}:: exclusions from the *%\{fontlicenses}* list
-
-====== Family-specific font declarations
-
-[horizontal]
-%\{fontpkgheader}:: multi-line container for package header directives
-
-.Semi-complex family declaration
-[source,rpm-spec]
-----
-%global fontfamily        PT Sans
-%global fontsummary       PT Sans, a grotesque pan-Cyrillic font family
-%global fontpkgheader     %{expand:
-Obsoletes: paratype-pt-sans-caption-fonts < %{version}-%{release}
-}
-%global fonts             PTS*.ttf PTN*.ttf PTC*.ttf
-%global fontconfs         %{SOURCE10}
-%global fontdescription   %{expand:
-The PT Sans family was developed as part of the “Public Types of Russian
-Federation” project. This project aims at enabling the peoples of Russia to
-read and write their native languages, using free/libre fonts. It is
-dedicated to the 300-year anniversary of the Russian civil type invented by
-Peter the Great from 1708 to 1710, and was realized with financial support
-from the Russian Federal Agency for Press and Mass Communications.}
-----
-
-… and more shell glob lists:
-
-[horizontal]
-%\{fontsex}:: exclusions from the *%\{fonts}* list
-%\{fontconfsex}:: exclusions from the *%\{fontconfs}* list
-%\{fontappstreams}:: the font family _appstream_ files, if any; those files are generated automatically if not specified
-%\{fontappstreamsex}:: exclusions from the *%\{fontappstreams}* list
-
-====== Remainer of the spec file
-
-Bulky documentation can be split in a separate subpackage
-
-.Documentation subpackage
-[source,rpm-spec]
-----
-%package   doc
-Summary:   %{name} optional documentation files
-BuildArch: noarch
-%description doc
-This package provides optional documentation files shipped with %{name}.
-
-[…]
-
-%files doc
-%license OFL.txt
-%doc *.pdf
-----
-
-Text files published for other systems may need recoding.
-
-[horizontal]
-%linuxtext:: allows converting upstream files to UTF-8 and Unix end of lines if necessary.
-It takes the following optional arguments:
-* `-e [encoding]` source OS encoding (automatically detected otherwise)
-* `-n`            do not recode files, only adjust folding and end of lines
-
-===== Annotated spec template
-
-Putting it all together:
-
-.spectemplate-fonts-1-full.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/fonts/spectemplate-fonts-1-full.spec[]
-----
-
-==== Packaging multiple font families
-
-Those patterns can be extended the following way,
-when packaging multiple font families,
-from a project named after the main packaged family.
-
-===== Macros and variables
-
-====== Shared font declarations
-
-`%\{foundry}`, `%\{fontlicense}`, `%\{fontlicensex}`, `%\{fontdocs}` and `%\{fontdocsex}` are applied to all font families,
-
-* unless overriden by the same variable, suffixed with a specific block number
-* for example `%\{fontdocs2}`
-
-A variable, can be used to share a description block:
-
-.Using a common description variable
-[source,rpm-spec]
-----
-%global common_description %{expand:
-IBM wanted Plex to be a distinctive, yet timeless workhorse — an alternative to
-its previous corporate font family, “Helvetica Neue”, for this new era. The
-Grotesque style was the perfect fit. Not only do Grotesque font families
-balance human and rational elements, the Grotesque style also came about during
-the Industrial Age, when IBM was born.}
-
-[…]
-
-%global fontfamily1       Plex Sans
-%global fontsummary1      IBM Plex Sans, the new grotesque IBM corporate font family
-%global fontpkgheader1 %{expand:
-Suggests: font(ibmplexsansmono)
-}
-%global fonts1            IBM-Plex-{Sans,Sans-*,Arabic}/fonts/complete/otf/*otf
-%global fontsex1          IBM-Plex-Sans-Thai-Looped/fonts/complete/otf/*otf
-%global fontconfs1        %{SOURCE11} 65-%{fontpkgname1}.conf
-%global fontdescription1  %{expand:
-%{common_description}
-This package provides the grotesque sans-serif variable-width IBM Plex Sans,
-the main font family of the Plex set.}
-
-%global fontfamily2       Plex Mono
-%global fontsummary2      IBM Plex Mono, the monospace grotesque coding font family of the Plex set
-%global fonts2            IBM-Plex-Mono/fonts/complete/otf/*otf
-%global fontconfs2        %{SOURCE12}
-%global fontdescription2  %{expand:
-%{common_description}
-This package provides the grotesque sans-serif fixed-width IBM Plex Mono, a
-little something for developers, because monospace does not need to be monotone.}
-----
-
-====== Family-specific font declarations
-
-* each font family is declared in a separate family-specific block,
-* each block is identified by a number, suffixed to the corresponding block variables,
-** for example `%\{fontfamily1}`
-* the zero-suffix block is used to generate SRPM metadata,
-* all the zero-suffix variables are aliased to no-suffix variables of the same name, and vice versa.
-
-====== Packaging macros
-
-* `%fontpkg`, `%fontbuild`, `%fontinstall`, `%fontcheck` and `%fontfiles` accept the following arguments:
-** `-a` process everything
-** `-z [number]` process the `[number]` declaration block
-* if no flag is specified they will only process the zero/no-suffix block
-** consequently, packaging multiple font families will usually require the `-a` option
-
-[horizontal]
-%{\fontmetapkg}:: generate font package headers. Optional arguments (usually unnecessary):
-
-* `-n [name]`  use `[name]` as metapackage name
-* `-s [variable]`  use the content of `[text]` as metapackage summary
-* `-d [variable]`  use the content of `[variable]` as metapackage description
-* `-z [numbers]`  restrict metapackaging to `[numbers]`è space-separated list of font package suffixes
-
-.Complex metapackaging example
-[source,rpm-spec]
-----
-%fontmetapkg -z 1,2,3
-
-%global lgcmetasummary All the font packages, generated from %{name}, Latin-Greek-Cyrillic subset
-%global lgcmetadescription %{expand:
-This metapackage installs all the font packages, generated from the %{name}
-source package, in a version restricted to coverage of Latin, Greek and
-Cyrillic.
-}
-
-%fontmetapkg -n dejavu-lgc-fonts-all -s lgcmetasummary -d lgcmetadescription -z 4,5,6
-----
-
-===== Annotated spec template
-
-Putting it all together:
-
-.spectemplate-fonts-2-multi.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/fonts/spectemplate-fonts-2-multi.spec[]
-----
-
-==== Packaging font families, released as part of something else
-
-The last pattern concerns the packaging one
-or several font families from a source rpm which is not named after the first packaged font family:
-
-* either because the project name differs from the main font family name,
-* or when the source archive and rpm are used to package more than fonts.
-
-It is almost identical to the previous one.
-
-===== Macros and variables
-
-====== Family-specific font declarations
-
-Do not declare a zero/no-suffix family-specific block,
-as it will attempt to generate SRPM metadata,
-and collide with existing SRPM declarations.
-
-===== Annotated spec template
-
-Putting it all together:
-
-.spectemplate-fonts-3-sub.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/fonts/spectemplate-fonts-3-sub.spec[]
-----
-
-== Rationale
-
-=== Legal
-
-Fonts are subject to specific copyright, trademark and patent laws.
-Reading our https://fedoraproject.org/wiki/Legal_considerations_for_fonts[fonts legal page] is recommended.
-
-=== Packaging unit: an ideal font family
-
-Font upstreams will often deviate from the OpenType model in their naming:
-
-* because mistakes happen,
-* because font formats are complex, with a long history, and a huge amount of legacy compability bagage,
-* because upstreams may focus on the artistic side of font creation, to the detriment of its technical side,
-* because upstreams may attempt to workaround problems in the legacy proprietary applications available on their platform of choice,
-* because upstreams may be dormant, and miss changes in the OpenType specification, or use font creation tools that have still not implemented those changes.
-
-Those deviations occur in upstream file names and upstream font file metadata.
-Upstream choices in those elements can not be relied upon to define useful and consistent font family boundaries.
-
-Shared font files, are no place to workaround application-specific problems.
-Fedora must apply the OpenType standard strictly,
-to enable the leveraging by Free Desktop applications,
-of the application capabilities this standard was designed to unlock.
-One can always find bits of code not updated to take into account decades-old changes in font standards.
-Waiting on this code to be fixed is being last, not _First_.
-
-=== Font file formats
-
-==== OpenType highlights
-
-===== Variable fonts
-
-Application support for variable fonts is sparse right now.
-They can not replace older OpenType formats yet.
-
-===== TT versus CFF
-
-* OpenType TT boasts https://en.wikipedia.org/wiki/Font_hinting[hinting] capabilities,
-but hinting is labor-intensive and does not scale to large-encoding fonts.
-In practice modern TT fonts are hinted using automated processes similar to the auto-hinter present in
-https://www.freetype.org/[freetype].
-* OpenType CFF lacks hinting but uses the excellent rasterizer Adobe
-https://opensource.googleblog.com/2013/05/got-cff.html[contributed] to freetype,
-achieving similar results.
-* Low-resolution rendering is increasingly irrelevant with the replacement of 96dpi screens by 4K+ HiDPI hardware.
-
-Therefore, don’t use hinting as a format selection criterium, unless you’re sure a human actually proofed the result on a modern renderer, at the screen pixel densities exercised by Fedora users.
-
-Choose the OpenType format best supported upstream,
-typically the one produced by upstream’s preferred font creation toolchain.
-For historical reasons the math behind OpenType TT and OpenType CFF differs,
-converting from one to the other may introduce corner cases problems.
-
-===== Collections
-
-While collection formats save some storage space,
-they introduce a high level of complexity packaging and application-side,
-make it impossible to install font families separately,
-and create a user-unfriendly environment.
-
-Avoid packaging `+*.ttc+` and `+*.otc+` files unless left no choice by upstream.
-
-==== Legacy deprecated formats
-
-Legacy formats are too limited to handle Unicode-level coverage,
-fail to declare their encoding,
-do not permit the kind of style selection expected in modern fonts,
-do not provide human-friendly naming layers, etc.
-They’re full of quirks and a source of (security) bugs in applications.
-
-In 2006,
-at the first https://www.freedesktop.org/wiki/TextLayout/[Text Layout] summit,
-all the major Free Desktop players agreed to converge on a unified text layout engine,
-built around the https://github.com/harfbuzz/harfbuzz[HarfBuzz] project and the OpenType format.
-As a result,
-modern Free Desktop applications and libraries
-https://bugzilla.redhat.com/show_bug.cgi?id=1753295[no]
-https://bugs.documentfoundation.org/show_bug.cgi?id=104701[longer]
-https://gitlab.gnome.org/GNOME/pango/issues/368[support]
-other formats.
-
-Use tools like
-https://fontforge.github.io/[fontforge]
-or
-https://fedoraproject.org/wiki/BitmapFontConversion[fonttosfnt]
-(provided by xorg-x11-font-utils) to
-https://gitlab.gnome.org/GNOME/pango/issues/386#note_568255[convert]
-legacy fonts to an OpenType format.
-Get it done upstream or script it within the `%build` section of your `spec` file.
-
-Like any other format conversion it will need some proofing.
-That’s why packaging fonts in a *single* *correct* format is a requisite for reliable text rendering.
-
-===== Web fonts
-
-Due to the limitations of the browsers that existed at the time,
-and due to the fear foundries had of widespread font piracy,
-initial support for web fonts used a hodgepole of obscure,
-broken and incomplete font formats (`svg`, `eot`, `woff`, etc).
-
-All major browsers have been https://caniuse.com/#feat=ttf[fixed] long ago to accept OpenType fonts.
-
-Do not package web fonts except in OpenType format.
-If your upstream still religiously cargo-cults other formats in its CSS files,
-get those fixed.
-
-The only remotely useful web font format is `woff`.
-Its advantages compared to OpenType are marginal at best on a well-configured web server.
-The sole remaining reason for `woff` existence is to serve as a light form of DRM for proprietary fonts
-(Normal applications do not read `woff` files).
-That concern does not apply to Fedora.
-Fedora wants to _share_.
-Any so-called web font can be useful in
-https://fedoramagazine.org/tuning-your-bash-or-zsh-shell-in-workstation-and-silverblue/[other]
-parts of the distribution.
-That requires distributing fonts in a common generic format.
-
-===== Postscript fonts
-
-The OpenType CFF outline format is derived from the one used in Postscript.
-It was designed by Adobe to permit lossless conversion of legacy Postscript fonts.
-The SFNT container used by OpenType is vastly more capable than the original PostScript format.
-
-Therefore, there’s no risk, and lots of advantages, in converting Postscript fonts.
-If their upstream does not want to bother, do not bother packaging the result.
-
-===== X11 core fonts
-
-Once upon a time every Linux GUI application used the so-called _Core fonts_ server-side X11 backend
-footnote:[Fonts accessed through the original _core_ X protocol,
-using tools like _mkfontdir_, _xfs_, _/etc/X11/fontpath.d/_, _XLFD_ strings, etc.
-See also this https://keithp.com/~keithp/talks/xtc2001/paper/[paper]
-written shortly before projects massively migrated to client-side fonts.].
-It was riddled with problems.
-The FLOSS developers finally gave up on it, declared it legacy and broken by design,
-and moved to client-side font handling (fontconfig).
-Nowadays almost no modern Linux GUI application uses the _Core fonts_ backend.
-Few (if any) people are willing to fix its remaining bugs.
-
-Therefore, unless your font has previously been registered in _Core fonts_,
-and the problems triggered by this font hopefully fixed, you *SHOULD NOT* declare it there.
-This is especially true of fonts in modern OpenType formats.
-
-The users of this legacy backend won't thank you for destabilizing it with new fonts.
-They value stability.
-Otherwise they'd have moved to fontconfig like everyone else a long time ago.
-
-=== Fontconfig
-
-Free Desktop systems rely on multiple upstreams to provide their fonts.
-They are heavily dependent on fontconfig to present a consistent user-friendly font pool in applications.
-High quality fontconfig rules are indispensable to permit easy substitution of font families,
-and to mask upstream messiness.
-
-Applying strict WWS rules helps applications identify all the parts of a font family,
-and makes selectors like bolder possible.
-
-Removing format attributes from `family` prevents breakage,
-when the technical format shipped by the distribution changes after an update.
-Because font technology continues to improve,
-format changes are bound to happen sooner or later.
-Applications can still request font format information via the fontconfig API if they need to.
-
-Removing coverage attributes from `family` enables merging all matching files in a single synthetic family.
-That is more user friendly,
-and prevents breakage when upstream decides to split the font family over different lines.
-Because creating a wide-coverage font family is a hard,
-long-term endeavour — Unicode is not finalized yet — such changes are common.
-
-The other decisions are just choosing good defaults for the font family.
-While fontconfig can take a guess at those,
-its guess will never be as accurate as packager decisions.
-Packagers can ask upstream for clarifications.
-Fontconfig can not.
-
-Remember that a lot of upstream naming decisions are taken to accomodate systems,
-that are missing an automatic font substition / font merging layer.
-The format and coverage information in `family` names is intended to help manual selection of font files.
-Our guidelines ask packagers to convert those to information fontconfig understands.
-Free Desktop systems can do a lot more,
-as long as the information provided to fontconfig is correct.
-
-=== Source (SRPM) package break-up
-
-As noted in the xref:index.adoc#bundling[Packaging Guidelines],
-Fedora packages should make every effort to avoid having multiple, separate,
-upstream projects bundled together in a single package.
-This applies equally to font packages.
-
-Multi-source packages are difficult to maintain and confusing to users.
-
-=== Installation (RPM) package break-up: font packages
-
-Once all the preceding has been done, a font package should only contain:
-
-* OpenType font files,
-* in a single OpenType format,
-** baring coverage constrains.
-* with WWS-compliant `style` values,
-* sharing the same `family` value,
-** except for optical sizing atttibutes, which are appended to the common `family` root.
-* fontconfig files,
-* appstream files,
-* legal files,
-* documentation files.
-
-=== Building
-
-Building from source ensures it will be possible to modify the font when problems are reported and upstream is not responsive.
-Sometimes that means working with upstream to sanitize its build processes.
-
-=== Packaging a font family in multiple OpenType formats; application support
-
-Fonts are comparatively bulky.
-Shipping fonts in multiple formats makes the situation worse on user systems, mirrors and live images.
-Every font family that ships in multiple formats,
-consumes space that could be used by another font package, enhancing the user experience.
-
-Because applications will make different choices in presence of multiple formats for the same font family,
-because different formats use different rasterization engines,
-because format conversions can introduce artefacts,
-shipping multiple formats reduces the effectiveness of Fedora QA.
-
-Most applications in Fedora support indifferently all OpenType formats,
-
-Most fonts in Fedora are only available in a single OpenType format,
-
-Rendering text in all the locales supported by Fedora requires using multiple fonts in multiple formats,
-
-Therefore packaging a font family in multiple OpenType formats should only be done as a limited exception.
diff --git a/guidelines/modules/ROOT/pages/Fortran.adoc b/guidelines/modules/ROOT/pages/Fortran.adoc
deleted file mode 100644
index 50886ea..0000000
--- a/guidelines/modules/ROOT/pages/Fortran.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-= Fortran Packaging Guidelines
-
-== Modules and include files
-
-The fortran modules files, ending in .mod are files describing a fortran 90 (and above) module API and ABI. These are not like C header files describing an API, they are compiler dependent and arch dependent, and not easily readable by a human being. They are nevertheless searched for in the includes directories by gfortran (in directories specified with `+-I+`).
-
-Due to the ABI specificity, the module directory used must be architecture specific. In addition each gfortran release (e.g. from 4.4 to 4.5) may lead to an incompatible change in the .mod files, therefore mass rebuilds of Fortran packages must take place when gfortran is updated.
-
-Fortran can also use include files, similar to C headers. Common used filename suffixes are '.inc' and '.h', although '.fh' has been used for files that are designed to function as public headers.
-
-== Packaging of Fortran programs
-
-Fortran programs in Fedora MUST be compiled, if possible, using the default Fortran compiler in Fedora, 'gfortran'. As usual, standard Fedora optimization flags `+%{optflags}+` MUST be used in the compilation.
-
-Fortran include files MUST be placed in the standard include directory: either directly in `+%{_includedir}+`, or if headers have general names or upstream recommends having an own directory, in e.g. `+%{_includedir}/%{name}+`.
-
-As Fortran modules are architecture and GCC version specific, they MUST be placed into `+%{_fmoddir}+` (or its package-specific subfolder in case the modules have generic names), which is owned by 'gcc-gfortran'. For directory ownership any packages containing Fortran modules MUST `+Requires: gcc-gfortran%{_isa}+`.
-
-To use the modules in the Fortran module directory, one needs to add `+-I%{_fmoddir}+` to the compiler flags (this is already included in `+FFLAGS+` used by `+%configure+`).
diff --git a/guidelines/modules/ROOT/pages/GAP.adoc b/guidelines/modules/ROOT/pages/GAP.adoc
deleted file mode 100644
index 1793add..0000000
--- a/guidelines/modules/ROOT/pages/GAP.adoc
+++ /dev/null
@@ -1,199 +0,0 @@
-= GAP Packaging Guidelines
-
-This document describes the conventions and customs
-surrounding the proper packaging of
-https://www.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.
-
-== Naming
-
-The main GAP package and its attendant libraries and help system
-are in packages named
-gap, gap-libs, gap-core, gap-online-help,
-gap-rpm-macros, gap-devel, gap-vim, and libgap.
-To distinguish add-on packages from these core packages,
-add-ons MUST have names of the form gap-pkg-foo.
-For example, the FGA add-on is named gap-pkg-fga.
-
-== Add-on Location
-
-Architecture-independent (noarch) packages MUST be installed in
-`+%{gap_libdir}/pkg/%{pkgname}+`,
-and architecture-specific packages in
-`+%{gap_archdir}/pkg/%{pkgname}+`,
-where `+%{pkgname}+` expands to the GAP name for the add-on.
-
-GAP add-ons are written to be installed simply by unpacking them
-in an existing GAP directory tree.
-For most add-ons,
-the only build action necessary is building the documentation.
-However,
-since the add-on authors assumed this would happen within the GAP tree,
-add-ons freely use relative paths to access GAP files.
-For example,
-packages that use TTH to build documentation (see below) commonly invoke
-`+../../../convert.pl+`.
-The RPM spec file MUST account for this,
-either by altering the add-on to point to paths under
-`+%{gap_libdir}+`,
-or by creating symbolic links
-to create the appearance that the build is taking place inside the GAP tree.
-If the add-on is altered for the build,
-the spec file SHOULD arrange
-for the original (unaltered) files to be installed,
-so that paths are correct after installation.
-
-GAP add-ons are frequently distributed in tarballs
-with a top-level directory of the form `addon-version`.
-The add-on SHOULD be installed without the version number.
-Documentation for one package often crosslinks
-into documentation for other packages.
-If the directories involved contain version numbers,
-then the crosslinks can be broken by a package upgrade.
-Avoid this situation by omitting the version numbers.
-GAP itself can retrieve the version number from the add-on's
-`+PackageInfo.g+` file, so no information is lost.
-
-== BuildRequires
-
-All add-ons MUST include `+BuildRequires: gap-devel+`,
-as that package contains essential tools
-needed for compiling binary modules and building documentation,
-as well as a set of RPM macros for use in spec files.
-Each add-on also MUST contain a `+BuildRequires+`
-that is dependent on the documentation style used by the GAP add-on.
-
-=== TTH
-
-Add-ons that use a `+buildman.pe+` or `+convert.pl+` script
-to build documentation also need `+BuildRequires: tth+`
-in order to build HTML documentation pages from TeX input.
-Some add-ons bundle these scripts,
-as well as a few auxiliary files.
-Add-ons containing any of the following files should be modified
-to link to the version of the file
-contained in the gap or gap-devel packages.
-
-* `+gapmacro.tex+` → `+%{gap_libdir}/doc/gapmacro.tex+`
-* `+gapmacrodoc.tex+` → `+%{gap_libdir}/doc/gapmacrodoc.tex+`
-* `+manualbib.xml+` → `+%{gap_libdir}/doc/manualbib.xml+`
-* `+manualbib.xml.bib+` → `+%{gap_libdir}/doc/manualbib.xml.bib+`
-* `+manualindex+` → `+%{gap_libdir}/doc/manualindex+`
-* `+buildman.pe+` → `+%{gap_libdir}/etc/buildman.pe+`
-* `+convert.pl+` → `+%{gap_libdir}/etc/convert.pl+`
-
-=== GAPDoc
-
-Add-ons that use GAPDoc to build documentation MUST include
-`+BuildRequires: GAPDoc-latex+`
-to pull in the necessary LaTeX packages.
-These packages do not need `+Requires: GAPDoc+`,
-since `+gap-core+` depends on GAPDoc.
-
-=== Autodoc
-
-Add-ons that use Autodoc to build documentation MUST include
-`+BuildRequires: gap-pkg-autodoc+`.
-Such packages do not need to include
-`+BuildRequires: GAPDoc-latex+`,
-as the Autodoc package `+Requires: GAPDoc-latex+`.
-
-== Requires, Recommends, and Suggests
-
-All add-ons MUST include `+Requires: gap-core+`,
-either directly or transitively.
-In addition, dependencies on other GAP packages,
-as recorded in `+PackageInfo.g+`,
-MUST be specified,
-with the exception of `+GAPDoc+`, as noted above.
-GAP has a 2-level dependency system,
-specified with
-`+NeededOtherPackages+`
-and `+SuggestedOtherPackages+`
-tags in `+PackageInfo.g+`.
-How these dependencies map onto the 3-level RPM dependency system
-of Requires, Recommends, and Suggests
-is left to the discretion of the Fedora packager.
-
-== Unnecessary Files
-
-GAP add-ons are intended to be unpacked in place
-within a GAP directory tree.
-Ordinarily,
-the entire distribution directory is copied into
-`+%{gap_libdir}/pkg+` or `+%{gap_archdir}/pkg+`.
-This includes the documentation directories,
-which are consumed by the tools contained in gap-online-help.
-However, some files are not needed in the final install directory.
-Files that should not appear there include:
-
-* Textual descriptions of the add-on, such as a README
-* License files (COPYING, COPYRIGHT, LICENSE, etc.)
-* Files for building documentation, often called `+make_doc+`
-* Files generated by LaTeX and associated tools,
-including files with these suffixes:
-** .aux
-** .bbl
-** .blg
-** .idx
-** .ilg
-** .ind
-** .log
-** .toc
-
-Note that License files MUST still be included in the package
-with the %license tag,
-and other documentation such as README files
-can be included as %doc.
-
-The `+%gap_copy_docs+` macro is intended
-to make installation of documentation files easier.
-For most packages,
-ensure that the `doc` subdirectory exists in the buildroot,
-then invoke the macro without arguments in `+%install+`.
-For special cases, two optional arguments can be given:
-
-* `+-d directory+`:
-for cases where the documentation directory is not named `doc`,
-or there are multiple documentation directories
-
-* `+-n package+`:
-the installed add-on directory name is assumed
-to be available from a macro `+%pkgname+`.
- If that is not the case,
-use this macro to give the main add-on directory name.
-
-== Documentation
-
-Since GAP documentation MUST be installed under
-`+%{gap_libdir}/pkg+` or `+%{gap_archdir}/pkg+`
-for the builtin documentation browser to find it,
-such documentation SHOULD NOT be duplicated with `+%doc+`.
-However, the documentation SHOULD still be marked as such
-so that documentation-free installs work as expected.
-Most add-ons SHOULD include `+%docdir+` declarations
-in the `+%files+` section of the spec file;
-e.g., `+%docdir %{gap_libdir}/pkg/%{pkgname}/doc+`
-and `+%docdir %{gap_libdir}/pkg/%{pkgname}/htm+`.
-
-== Other RPM macros
-
-Other RPM macros that may be useful
- for GAP add-on spec files include the following:
-
-* `+%gap_version+`:
-the version of the main GAP package; e.g., 4.12.0.
-
-* `+%gap_archdir+`:
- parent directory for arch-specific GAP add-ons,
-currently `+%{_libdir}/gap+`.
-
-* `+%gap_libdir+`:
- the root directory of the GAP installation, currently `+%{_datadir}/gap+`.
-
-* `+%gap_arch+`:
- the GAP name for the build architecture; e.g., `x86_64-redhat-linux-gnu`.
diff --git a/guidelines/modules/ROOT/pages/Golang.adoc b/guidelines/modules/ROOT/pages/Golang.adoc
deleted file mode 100644
index df7eed1..0000000
--- a/guidelines/modules/ROOT/pages/Golang.adoc
+++ /dev/null
@@ -1,698 +0,0 @@
-= Golang Packaging Guidelines
-:last-reviewed: 2025-10-15
-:gvt: https://fedora.gitlab.io/sigs/go/go-vendor-tools/
-
-
-This document details best practices for packaging Golang packages.
-
-[NOTE]
-====
-:vendored-change: https://fedoraproject.org/wiki/Changes/GolangPackagesVendoredByDefault
-
-The xref:Golang_old.adoc[previous version] of these Guidelines
-involved creating separate `+-devel+` packages containing the Go source code
-for each library dependency.
-As of {vendored-change}[Changes/GolangPackagesVendoredByDefault],
-new Go packages MUST be built with vendored dependencies,
-as outlined in the current version of the Guidelines.
-====
-
-== go2rpm
-
-https://gitlab.com/fedora/sigs/go/go2rpm[go2rpm] is a tool that automates many of these steps.
-It is advisable to try `+go2rpm --name NAME --profile vendor IMPORT_PATH+` first
-before attempting to write a SPEC by hand.
-go2rpm will generate a Guidelines-compliant spec file,
-download the upstream sources,
-create a vendor archive using `+go_vendor_archive+` from Go Vendor Tools
-and then use `+go_vendor_license+` to
-scan the upstream sources and vendored dependencies for license files,
-prompt the user for any licenses it could not detect,
-and then generate a cumulative SPDX expression.
-
-== Import Path
-
-In Golang, packages are referenced by full URLs listed in the project's `+go.mod+` file.
-
-[source,rpm-spec]
-----
-%global goipath     github.com/kr/pretty
-----
-
-== Naming
-:rename-policy: xref:index.adoc#renaming-or-replacing-existing-packages
-
-New Golang library packages are no longer allowed,
-so all Golang packages are user-facing applications that MUST be named
-according to the standard xref:Naming.adoc[Naming Guidelines].
-In particular, vendored Go packages MUST NOT have a `+golang-+` prefix,
-unless that is part of the upstream name of the project.
-
-This also applies to existing packages.
-When converting a package with a `+golang-+` prefix that was created under the
-old guidelines to use vendored dependencies,
-the package MUST go through the {rename-policy}[package rename process].
-This guideline seeks to create a clear separation between packages created under
-the old approach and the new vendored method
-and to avoid cases where `+-devel+` subpackages are removed from existing `+golang-+`
-packages and then merged back to stable branches.
-
-== Go Language Architectures
-
-To compile on various architectures, golang and gcc-go compilers are available.
-The golang compiler currently supports x86, x86_64, ppc64le, ppc64 (partially,
-see upstream issue#13192), s390x, armv7hl and aarch64.
-
-Binaries SHOULD set ExclusiveArch so that we only attempt to build packages on
-those arches.
-This is now automatically added by the `+%gometa+` macro by leveraging the
-`+%{golang_arches}+` macro.
-Packagers can exclude `+%ix86+`
-(see https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval[Changes/EncourageI686LeafRemoval])
-by passing `+-f+` to the `+%gometa+` macro.
-The `+-f+` flag tells `+%gometa+` to set `+ExclusiveArch: %{golang_arches_future}+`
-instead of `+ExclusiveArch: %{golang_arches}+`.
-`+%{golang_arches_future}+` includes the same architectures as
-`+{golang_arches}+` sans `+%ix86+`.
-
-== Go compiler flags
-
-:macros-go-compilers: https://gitlab.com/fedora/sigs/go/go-rpm-macros/-/blob/main/rpm/macros.d/macros.go-compilers-golang?ref_type=heads
-
-=== Preserve compiler flags
-
-Packages MUST preserve the Fedora golang compiler flags
-by using the `+%gobuild+` macro or by passing the appropriate `+%gobuild_*flags+` macros to an upstream build script.
-
-[source, rpm-spec]
-----
-# Using %gobuild
-%gobuild -o %{gobuilddir}/bin/%{name} %{goipath}
-
-# Using a simple upstream build script
-%make_build BUILD_OPTS=%{gobuild_baseflags_shescaped}
-
-# Using an upstream build script that provides separate options for ldflags
-%make_build \
-  BUILD_OPTS=%{gobuild_baseflags_shescaped} \
-  GO_LDFLAGS=%{gobuild_ldflags_shescaped}
-----
-
-See the inline comments in {macros-go-compilers}[macros.go-compilers-golang]
-for more information on passing the compiler flags to an upstream build script.
-
-[TIP]
-====
-It is recommended to use the `+%gobuild+` macro if possible.
-Some upstream build scripts may not provide a proper way to pass
-additional flags to the compiler or have other issues that can be a source of bugs.
-When using `+%gobuild+`, make sure to set the appropriate linker flags and build tags
-as described below.
-====
-
-=== Passing additional flags
-
-Go supports passing additional linker flags
-(for example, to enable `+--version+` functionality)
-and build tags for conditional compilation.
-When using an upstream build script, these may be set automatically.
-Otherwise, the packager should set them manually.
-
-[IMPORTANT]
-====
-Make sure to consult the upstream build process and documentation to determine
-what linker flags you may need to include to properly encode the version into
-the binary for projects that provide a flag like `+--version+` or what build
-tags to select to enable additional optional features.
-====
-
-==== Linker flags
-
-In some cases, it may be necessary to pass additional flags to the Go linker.
-This can be accomplished by setting the `+$GO_LDFLAGS+` environment variable
-which will then be read by the macros.
-
-[source, rpm-spec]
-----
-# The correct value to pass to -X differs between projects; this is an example.
-export GO_LDFLAGS="-X %{goipath}/internal.Version=%{version}"
-----
-
-Packages MUST NOT set Go linker flags using the `+$LDFLAGS+` environment variable.
-This is supported for backwards compatibility, but it is deprecated.
-
-==== Build tags
-
-Go supports build tags to conditionally include or exclude code from the build.
-To pass build tags to the Go compiler, set `+$GO_BUILDTAGS+` to a
-space-separated list of tags.
-
-[source, rpm-spec]
-----
-# These tags are just examples. Each project has its own.
-export GO_BUILDTAGS="systemd selinux"
-----
-
-Packages MUST NOT set Go tags using the `+$BUILDTAGS+` environment variable.
-
-== Macro dependencies
-
-Packages MUST have `+BuildRequires: go-rpm-macros+` to pull in the Go macros and
-compiler.
-
-This is automated by the `+%gometa+` macro.
-
-Packages that use the `+%go_vendor_license_*+` macros MUST have
-`+BuildRequires: go-vendor-tools+`.
-
-== Vendored dependencies
-
-:gvt-security: https://fedora.gitlab.io/sigs/go/go-vendor-tools/scenarios/#security-updates
-
-Packages MUST vendor their Go module dependencies.
-Packagers SHOULD use the `+go_vendor_archive+` command from {gvt}[Go Vendor Tools] to
-generate a reproducible vendor archive.
-Packages that do not use Go Vendor Tools must include a script or other
-standardized, documented procedure to download sources with
-`go mod vendor` and reproducibly produce a tarball.
-Packagers SHOULD regenerate vendor archives themselves,
-even if upstreams include a vendor directory in their upstream sources.
-This allows for easier {gvt-security}[security updates using Go Vendor Tools].
-
-Conventionally, `+Source0+` in the specfile is the primary archive,
-and `+Source1+` is the vendor archive,
-and the values are automatically filled in using the forge macros.
-
-[source, rpm-spec]
-----
-Source0:        %{gosource}
-# %%archivename is the basename as the archive provided
-# by %%gosource without the extension.
-Source1:        %{archivename}-vendor.tar.bz2
-# go-vendor-tools configuration generated by go2rpm
-Source2:        go-vendor-tools.toml
-----
-
-Then, run `+go_vendor_archive create <PACKAGE_NAME>.spec+` to create a
-vendor tarball.
-
-[#bundled-provides]
-=== Bundled provides
-:go_mod_vendor_attr: https://gitlab.com/fedora/sigs/go/go-rpm-macros/-/blob/main/rpm/fileattrs/go_mod_vendor.attr?ref_type=heads
-
-Packages MUST include `+bundled(golang(IMPORT_PATH)) = VERSION+` Provides for
-all vendored Go modules.
-This is handled automatically by {go_mod_vendor_attr}[a dependency generator].
-It runs on any `+modules.txt+` file in a license directory.
-Mark the `+vendor/modules.txt+` file with `+%license+` in `+%files+`,
-and then the generator will scan the file and create the `+bundled()+` Provides.
-`+vendor/modules.txt+` is included in `+go_vendor_license_filelist+` by default
-(see <<installing-licenses>>) so most packages will not need to do this manually.
-
-[source, rpm-spec]
-----
-# Only necessary to include explicitly when not using %%go_vendor_license_filelist
-%license vendor/modules.txt
-----
-
-== Licensing
-
-:generate-go2rpm: https://fedora.gitlab.io/sigs/go/go-vendor-tools/scenarios/#generate-go2rpm
-:manual-update: https://fedora.gitlab.io/sigs/go/go-vendor-tools/scenarios/#manual-update
-:post_commands: https://fedora.gitlab.io/sigs/go/go-vendor-tools/config/#archive&#x2D;&#x2D;post_commands
-:metaPrefixes: https://github.com/golang/go/blob/ac94297758f3d83fca5ffa16cd179bb098bbd914/src/cmd/go/internal/modcmd/vendor.go#L398-L415
-
-
-Packages must follow the xref:LicensingGuidelines.adoc[Fedora Licensing Guidelines].
-For vendored Go packages, this means that the license files of the main
-project as well as all of the vendored Go modules MUST be included in the package
-and marked with `+%license+`.
-Each vendored Go module MUST include a license file;
-Go modules that are missing license files MUST NOT be included in vendored
-archives until the licensing is clarified.
-
-Additionally, the package's `+License:+` tag MUST include a cumulative SPDX
-expression encompassing both the main package and the vendored Go modules.
-
-[#go-vendor-tools-licensing]
-== Licensing with Go Vendor Tools
-
-:licensing-config: https://fedora.gitlab.io/sigs/go/go-vendor-tools/config/#licensing
-:manual-detection: https://fedora.gitlab.io/sigs/go/go-vendor-tools/scenarios/#manually-detecting-licenses
-:go-vendor-license-check: https://fedora.gitlab.io/sigs/go/go-vendor-tools/man/rpm_macros/#go_vendor_license_check
-
-{gvt}[Go Vendor Tools] provides the `+go_vendor_license+` command and macros
-to help determine the correct `+License:+` expression and install license files
-as mandated by the previous section.
-
-Packagers MUST run `+go_vendor_license report+` (either directly, through go2rpm, or
-using the {go-vendor-license-check}[%go_vendor_license_check] macro in a _local_ mock build)
-and double check its output before uploading sources to the lookaside cache.
-Any errors MUST be addressed.
-If any part of the output is wrong, `+go_vendor_license+` 's behavior can be modified
-in {licensing-config}[the licensing section of the Go Vendor Tools config file].
-
-This document only outlines the standard usage of Go Vendor Tools needed to comply
-with the Guidelines — consult the {gvt}[Go Vendor Tools documentation] for
-details on advanced usage.
-Packagers can follow the scenarios documentation to
-{generate-go2rpm}[generate a new specfile with go2rpm] or
-{manual-update}[update existing specfiles for new upstream versions]
-to run `+go_vendor_license+` and make sure that the License is valid and
-automatically update it if necessary before running a full build.
-
-[WARNING]
-====
-While Go Vendor tools provide facilities to scan for licenses and generate SPDX
-expressions,
-it is still the packager's responsibility to perform a basic check of the
-output and ensure adherence to the Fedora Licensing Guidelines, including
-ensuring that all keys in the License tag are allowed licenses in Fedora,
-before uploading any sources to the lookaside cache.
-
-If necessary, the license expression for individual files can be
-overridden in the config file, {manual-detection}[as outlined in the scenarios documentation].
-====
-
-=== go-vendor-tools.toml
-
-:config-reference: https://fedora.gitlab.io/sigs/go/go-vendor-tools/config/
-
-Packages MUST include a `+go-vendor-tools.toml+` file to specify the license
-detector backend and other configuration options.
-See the {config-reference}[configuration reference] for more information.
-The recommended approach is to use `+go2rpm+` that automatically creates
-a valid `+go-vendor-tools.toml+`.
-A minimal configuration looks like this:
-
-[source,toml]
-----
-[licensing]
-detector = "askalono"
-----
-
-This file is used by the macros and is conventionally included in the specfile
-as `+Source2:+`, just below the upstream archive and the
-`+go_vendor_archive+`-generated tarball.
-In this document, `+%{S:2}+` (expands to the path to `+Source2+`) will be used
-to represent the path to the Go Vendor Tools config file.
-
-
-=== Installing go-vendor-tools
-
-:go-vendor-license-buildrequires: https://fedora.gitlab.io/sigs/go/go-vendor-tools/man/rpm_macros/#go_vendor_license_buildrequires
-
-Packages that use the Go Vendor Tools macros MUST have `+BuildRequires:
-go-vendor-tools+` and use the
-{go-vendor-license-buildrequires}[%go_vendor_license_buildrequires] macro
-to generate requirements needed for the selected license detector backend.
-
-[source,rpm-spec]
-----
-BuildRequires:  go-vendor-tools
-----
-
-[source,rpm-spec]
-----
-%generate_buildrequires
-%go_vendor_license_buildrequires -c %{S:2}
-----
-
-[#installing-licenses]
-=== Installing licenses
-
-:go-vendor-license-install: https://fedora.gitlab.io/sigs/go/go-vendor-tools/man/rpm_macros/#go_vendor_license_install
-:go-vendor-license-filelist: https://fedora.gitlab.io/sigs/go/go-vendor-tools/man/rpm_macros/#go_vendor_license_filelist
-
-Packagers SHOULD use the
-{go-vendor-license-install}[%go_vendor_license_install] macro to install
-license files of the main project and all vendored Go modules.
-By default, this macro will install the license files into main package's license directory.
-The macro also copies the `+vendor/modules.txt+` file to the license directory to
-enable the Golang `+bundled()+` generator (see <<bundled-provides>>).
-
-[source,rpm-spec]
-----
-# Install into the main package's license directory
-%go_vendor_license_install -c %{S:2}
-----
-
-Then, the macro will populate
-{go-vendor-license-filelist}[%\{go_vendor_license_filelist}] with a list of
-files that can be passed to `+%files -f+`.
-
-[source,rpm-spec]
-----
-%files -f %{go_vendor_license_filelist}
-----
-
-=== Checking licenses
-
-:go-vendor-license-check: https://fedora.gitlab.io/sigs/go/go-vendor-tools/man/rpm_macros/#go_vendor_license_check
-
-As stated, packagers MUST check licenses using Go Vendor Tools before uploading
-sources to the lookaside cache.
-Any errors raised by `+go_vendor_license+` MUST be addressed.
-
-As an additional measure, the
-{go-vendor-license-check}[%go_vendor_license_check macro] runs the same license
-scan as the `+go_vendor_license report+` command.
-Packages SHOULD use `+go_vendor_license_check+` in `+%check+` so the package
-build will fail if there are any license errors.
-Go Vendor Tools scans the upstream sources and vendored libraries for license files
-and generates a cumulative SPDX expression.
-Also, the macro checks that the expression in the package's License tag is
-equivalent (regardless of order or possible expression simplification)
-to what `+go_vendor_license report+` expects.
-
-[source,rpm-spec]
-----
-# Scan licenses and verify that the License tag is equivalent to what
-# go_vendor_license calculates.
-%go_vendor_license_check -c %{S:2}
-
-# The macro can also compare a license expression stored in a macro with
-# go_vendor_license's output.
-%go_vendor_license_check -c %{S:2} %{go_licenses}
-----
-
-=== In case of missing licenses
-
-`+go_vendor_license+` checks if any Go module is missing a license file.
-Again, Go modules that are missing license files MUST NOT be included in
-vendored archives until the situation is fixed upstream.
-
-In some cases, `+go mod vendor+` may fail to download a project's license file,
-even if it exists for the equivalent version in the upstream repository.
-This is usually because the license files have non-standard names or because
-the licenses are installed in a subdirectory instead of the root of the module.
-In the former case, `+go_vendor_archive+` MAY be configured using
-{post_commands}[post_commands] to download the license file from the upstream
-repository as a temporary measure, but packagers MUST report this to upstream
-and ask it to rename the license file to
-{metaPrefixes}[a format supported by `+go mod vendor+`].
-If the license file is included in a subdirectory of a module, the file should
-be copied to the root directory to satisfy the Go Vendor Tools license checker.
-
-== Testing
-
-:gocheck2: https://fedora.gitlab.io/sigs/go/go-vendor-tools/man/rpm_macros/#gocheck2
-
-You SHOULD run unit tests.
-
-Some tests may be disabled, especially the following kinds of unit tests are
-incompatible with a secure build environment such as mock:
-
-* tests that call a remote server or API over the Internet,
-* tests that attempt to reconfigure the system,
-* tests that rely on a specific app running on the system, like a database
-  or syslog server.
-
-If a test is broken for some other reason, you can disable it the same way.
-However, you SHOULD also report the problem upstream. Remember to trace in a
-comment why each check was disabled, with links to eventual upstream problem
-reports.
-
-Tests can be run using {gocheck2}[the %gocheck2 macro] which calls `+go test+`
-internally while preserving the Fedora build flags and providing additional
-options to skip certain tests.
-
-Packages MUST NOT use the deprecated legacy `+%gocheck+` macro.
-
-== Go modules mode
-
-:gomod: https://go.dev/ref/mod
-:go111module: https://go.dev/ref/mod#mod-commands
-:embed: https://pkg.go.dev/embed
-
-Packages SHOULD enable Go modules mode by including
-`+%global gomodulesmode GO111MODULE=on+` in the specfile
-to set the `+GO111MODULE+` environment variable.
-Customarily, this definition is included at the beginning of `+%build+`
-before the `+%gobuild+` invocation.
-
-[NOTE]
-====
-{gomod}[Go modules] are the system `+go+` uses to manage dependencies.
-Go modules mode replaces `+$GOPATH+` mode (the previous dependency management system).
-Go can be configured to use modules or `+$GOPATH+` mode by setting the
-{go111module}[$GO111MODULE environment variable] to `+on+`, `+off+`, or `+auto+`.
-`+auto+` is the upstream default.
-By default, `+%gobuild+` in Fedora sets `+GO111MODULE=off+` for compatibility
-with the legacy Golang Packaging Guidelines but this approach is not
-recommended for new packages built with vendored dependencies.
-Modules mode should be used so `+%gobuild+` will read modules metadata and
-include metadata about package dependencies in the binary
-and to make sure {embed}[Go embed] works properly.
-====
-
-== Macros
-
-:gvt-macros: https://fedora.gitlab.io/sigs/go/go-vendor-tools/man/rpm_macros/
-:forge-srpm-macros: https://git.sr.ht/~gotmax23/forge-srpm-macros/
-:macros-go-rpm: https://gitlab.com/fedora/sigs/go/go-rpm-macros/-/blob/main/rpm/macros.d/macros.go-rpm
-:macros-go-srpm: https://gitlab.com/fedora/sigs/go/go-srpm-macros/-/blob/main/srpm/macros.d/macros.go-srpm
-:forge-wrappers: https://gitlab.com/fedora/sigs/go/go-rpm-macros/-/blob/main/doc/forge-wrappers.adoc?ref_type=heads
-
-The RPM macros provided by `+go-vendor-tools+` are used to validate and install licenses.
-See {gvt-macros}[Go Vendor Tools RPM Macros docs] and <<go-vendor-tools-licensing>>.
-
-`+go-rpm-macros+` is primarily responsible for the `+%gobuild+` macro that calls
-`+go build+` with Fedora's build flags.
-
-`+go-rpm-macros+` also provides wrappers around the
-xref:SourceURL.adoc[Forge macros] from the {forge-srpm-macros}[forge-srpm-macros] package
-that makes it easier to specify the Source URL and unpack sources for Go projects
-hosted on common software forges like Github.
-These macros include `%gometa`, `%gosource`, and `%goprep`.
-Packagers can use these macros instead of specifying sources and calling
-`+%autosetup+` / `+%setup+` manually.
-See {forge-wrappers}[the standalone docs] and example specfile in these
-guidelines for more information.
-
-== Example
-
-
-=== go-vendor-tools configuration
-
-These entries were generated automatically by go2rpm.
-All Go packages MUST have a go-vendor-tools.toml file
-committed to distgit alongside the specfile.
-
-[source,toml]
-.go-vendor-tools.toml
-----
-[archive]
-
-[licensing]
-detector = "askalono"
-
-[[licensing.licenses]]
-path = "vendor/github.com/google/shlex/COPYING"
-sha256sum = "cfc7749b96f63bd31c3c42b5c471bf756814053e847c10f3eb003417bc523d30"
-expression = "Apache-2.0"
-
-[[licensing.licenses]]
-path = "vendor/github.com/jwalton/gchalk/LICENSE-chalk"
-sha256sum = "44e453533edb9f1c037cb260c58f66f1d9b2e7823a07407cd6d04320e3925fea"
-expression = "MIT"
-
-[[licensing.licenses]]
-path = "vendor/github.com/jwalton/gchalk/pkg/ansistyles/LICENSE-ansi-styles"
-sha256sum = "310f4b4de77142b34acc5a58de93558fde5dea75891c7822b4086f71372ec983"
-expression = "MIT"
-
-[[licensing.licenses]]
-path = "vendor/github.com/jwalton/go-supportscolor/LICENSE"
-sha256sum = "892282511d65ac08025fbabcd8af330d0aa94e459d81a818251ff5a934383816"
-expression = "MIT"
-
-[[licensing.licenses]]
-path = "vendor/gopkg.in/yaml.v3/LICENSE"
-sha256sum = "d18f6323b71b0b768bb5e9616e36da390fbd39369a81807cca352de4e4e6aa0b"
-expression = "MIT AND (MIT AND Apache-2.0)"
-----
-
-
-=== Specfile with forge macro wrappers
-
-This is the default method used by go2rpm and is the current convention for Go
-packages.
-
-[source,rpm-spec]
-.ov.spec
-----
-# Generated by go2rpm 1.17.1 (with extra code comments added manually)
-%bcond check 1
-
-# https://github.com/noborus/ov
-%global goipath         github.com/noborus/ov
-Version:                0.43.0
-
-%gometa -L -f
-
-Name:           ov
-Release:        %autorelease
-Summary:        Feature-rich terminal-based text viewer
-
-# Generated by go-vendor-tools
-License:        Apache-2.0 AND BSD-3-Clause AND MIT AND MPL-2.0
-URL:            %{gourl}
-Source0:        %{gosource}
-# Generated by go-vendor-tools
-Source1:        %{archivename}-vendor.tar.bz2
-# Go Vendor Tools configuration generated by go2rpm
-Source2:        go-vendor-tools.toml
-
-BuildRequires:  go-vendor-tools
-
-%description
-Feature-rich terminal-based text viewer. It is a so-called terminal pager.
-
-%prep
-# Unpack upstream sources (Source0) and apply patches if they exist.
-# This also creates the %%{gobuilddir} directory used to store the binary built
-# during %%build.
-%goprep -p1
-# Unpack the vendor archive in Source1.
-tar -xf %{S:1}
-
-%generate_buildrequires
-# Install license scanner dependencies.
-%go_vendor_license_buildrequires -c %{S:2}
-
-%build
-# Enable Go modules mode as required by the Guidelines.
-%global gomodulesmode GO111MODULE=on
-# Set version in binary. The exact value to pass to -X differs by project.
-export GO_LDFLAGS="-X main.Version=%{version}"
-# Build the binary
-%gobuild -o %{gobuilddir}/bin/ov %{goipath}
-# Generate shell completions
-%{gobuilddir}/bin/%{name} --completion bash > %{name}.bash
-%{gobuilddir}/bin/%{name} --completion fish > %{name}.fish
-%{gobuilddir}/bin/%{name} --completion zsh  > %{name}.zsh
-
-%install
-# Install license files
-%go_vendor_license_install -c %{S:2}
-
-# Install binaries built during %%build
-install -m 0755 -vd                     %{buildroot}%{_bindir}
-install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/
-
-# Install shell completions generated during %%build
-install -Dpm 0644 ov.bash %{buildroot}%{bash_completions_dir}/ov
-install -Dpm 0644 ov.fish %{buildroot}%{fish_completions_dir}/ov.fish
-install -Dpm 0644 ov.zsh  %{buildroot}%{zsh_completions_dir}/_ov
-
-%check
-# Perform license check
-%go_vendor_license_check -c %{S:2}
-# Run Go unit tests
-%if %{with check}
-%gocheck2
-%endif
-
-%files -f %{go_vendor_license_filelist}
-%doc README.md
-%{_bindir}/ov
-%{bash_completions_dir}/ov
-%{fish_completions_dir}/ov.fish
-%{zsh_completions_dir}/_ov
-
-%changelog
-%autochangelog
-----
-=== Specfile with manual defintions
-
-This above approach is used by default in go2rpm but Go
-packages can also be built without the forge macros.
-Be sure to include the manual dependency on `+go-rpm-macros+` and the
-appropriate ExclusiveArch invocation.
-
-[source,rpm-spec]
-.ov.spec
-----
-%bcond check 1
-
-Name:           ov
-Version:        0.43.0
-Release:        %autorelease
-Summary:        Feature-rich terminal-based text viewer
-# Generated by go-vendor-tools
-License:        Apache-2.0 AND BSD-3-Clause AND MIT AND MPL-2.0
-URL:            https://github.com/noborus/ov
-Source0:        %{url}/archive/v%{version}/ov-%{version}.tar.gz
-# Generated by go-vendor-tools
-Source1:        ov-%{version}-vendor.tar.bz2
-Source2:        go-vendor-tools.toml
-
-ExclusiveArch:  %{golang_arches_future}
-BuildRequires:  go-rpm-macros
-BuildRequires:  go-vendor-tools
-
-%description
-Feature-rich terminal-based text viewer. It is a so-called terminal pager.
-
-%prep
-# Unpack upstream sources (Source0) and apply patches if they exist.
-%autosetup -p1
-# Unpack the vendor archive in Source1.
-tar -xf %{S:1}
-
-%generate_buildrequires
-# Install license scanner dependencies.
-%go_vendor_license_buildrequires -c %{S:2}
-
-%build
-# Enable Go modules mode as required by the Guidelines.
-%global gomodulesmode GO111MODULE=on
-# Set version in binary. The exact value to pass to -X differs by project.
-export GO_LDFLAGS="-X main.Version=%{version}"
-# Build the binary
-%gobuild -o ov .
-# Generate shell completions
-./ov --completion bash > ov.bash
-./ov --completion fish > ov.fish
-./ov --completion zsh  > ov.zsh
-
-%install
-# Install license files
-%go_vendor_license_install -c %{S:2}
-
-# Install binaries built during %%build
-install -Dp ./ov -t %{buildroot}%{_bindir}
-
-# Install shell completions generated during %%build
-install -Dpm 0644 ov.bash %{buildroot}%{bash_completions_dir}/ov
-install -Dpm 0644 ov.fish %{buildroot}%{fish_completions_dir}/ov.fish
-install -Dpm 0644 ov.zsh  %{buildroot}%{zsh_completions_dir}/_ov
-
-%check
-# Perform license check
-%go_vendor_license_check -c %{S:2}
-# Run Go unit tests
-%if %{with check}
-%gocheck2
-%endif
-
-%files -f %{go_vendor_license_filelist}
-%doc README.md
-%{_bindir}/ov
-%{bash_completions_dir}/ov
-%{fish_completions_dir}/ov.fish
-%{zsh_completions_dir}/_ov
-
-%changelog
-%autochangelog
-----
-
-== Additional resources
-
-:go-rpm-macros-docs: https://gitlab.com/fedora/sigs/go/go-rpm-macros/-/tree/main/doc?ref_type=heads
-:go2rpm: https://gitlab.com/fedora/sigs/go/go2rpm
-
-- {gvt}[Go Vendor Tools documentation]
-- {go-rpm-macros-docs}[Go RPM Macros documentation]
-- {go2rpm}[go2rpm project on Gitlab]
diff --git a/guidelines/modules/ROOT/pages/Golang_advanced.adoc b/guidelines/modules/ROOT/pages/Golang_advanced.adoc
deleted file mode 100644
index f9272e9..0000000
--- a/guidelines/modules/ROOT/pages/Golang_advanced.adoc
+++ /dev/null
@@ -1,296 +0,0 @@
-= Advanced uses cases
-:last-reviewed: 2019-06-19
-
-== Shipping additional files
-
-If you need to ship additional files in your source code packages, you can use
-the following macros in the preamble:
-
-* `+%global goextensions+`    A space separated list of extensions that should
-                              be included in the devel package in addition to
-                              Go default file extensions.
-* `+%global gosupfiles+`:     A space-separated list of shell globs matching
-                              other files to include in the devel package.
-* `+%global gosupfilesex+`    A space-separated list of shell globs matching
-                              other files you wish to exclude from package lists.
-                              Only works with “gosupfiles”-specified files.
-
-For example, if you have glide files to ship:
-
-[source,rpm-spec]
-----
-%global gosupfiles glide.yaml glide.lock
-----
-
-== Additional header declarations
-
-Use `+%godevelheader+` to add specific subpackage declarations. For example, you
-might want to require the main package containing the binaries, or
-Obsoletes/Provides another package in case of renaming.
-
-[source,rpm-spec]
-----
-%global godevelheader %{expand:
-Requires:
-Obsoletes:
-Provides:
-}
-----
-
-== Dealing with cyclic dependencies
-
-In many cases, you'll encounter packages that depend on each other, also known
-as cyclic dependencies, making it difficult to build either package.
-
-Typically, when you have a problematic requires, it is only used in specific
-project subpackages, and most project dependents do not need those subpackages
-directly or indirectly. The idea is then to affect the goipaths associated with
-the problematic subpackages to a separate -devel rpm package, to simplify
-your dependency graph.
-
-Let's take for example the following packages: `+cloud.google.com/go+` and
-`+golang.org/x/oauth2+`.
-
-`+cloud.google.com/go+` has the following dependency graph:
-
-
-[source]
-----
-github.com/golang/mock/gomock
-github.com/golang/protobuf/proto
-github.com/golang/protobuf/ptypes
-github.com/golang/protobuf/ptypes/any
-github.com/golang/protobuf/ptypes/duration
-github.com/golang/protobuf/ptypes/empty
-github.com/golang/protobuf/ptypes/struct
-github.com/golang/protobuf/ptypes/timestamp
-github.com/golang/protobuf/ptypes/wrappers
-github.com/google/btree
-github.com/google/go-cmp/cmp
-github.com/google/martian
-github.com/google/martian/fifo
-github.com/google/martian/httpspec
-github.com/google/martian/martianhttp
-github.com/google/martian/martianlog
-github.com/google/martian/mitm
-github.com/google/pprof/profile
-github.com/googleapis/gax-go/v2
-go.opencensus.io/plugin/ocgrpc
-go.opencensus.io/stats
-go.opencensus.io/stats/view
-go.opencensus.io/tag
-go.opencensus.io/trace
-golang.org/x/build/kubernetes
-golang.org/x/build/kubernetes/api
-golang.org/x/build/kubernetes/gke
-golang.org/x/oauth2
-golang.org/x/oauth2/google
-golang.org/x/oauth2/jwt
-golang.org/x/sync/errgroup
-golang.org/x/sync/semaphore
-golang.org/x/text/language
-golang.org/x/time/rate
-[…]
-----
-
-And `+golang.org/x/oauth2+` has the following dependency graph:
-
-[source]
-----
-cloud.google.com/go/compute/metadata
-golang.org/x/net/context/ctxhttp
-----
-
-As you can see both packages depend on each other.
-If we search for where `+cloud.google.com/go+` is used in
-`+golang.org/x/oauth2+`:
-
-[source,bash]
-----
-grep -nr "cloud.google.com/go/compute/metadata" $GOPATH/src/golang.org/x/oauth2
-
-/home/user/go/src/golang.org/x/oauth2/google/default.go:17:      "cloud.google.com/go/compute/metadata"
-/home/user/go/src/golang.org/x/oauth2/google/google.go:15:       "cloud.google.com/go/compute/metadata"
-----
-
-We can see that it is used in the `+golang.org/x/oauth2/google+` subpackage,
-which is precisely the subpackage needed by `+cloud.google.com/go+`. It is thus
-not possible to split `+golang.org/x/oauth2/google+` into separate devel
-subpackage to resolve our cyclic dependency graph.
-
-
-Now if we search for where `+golang.org/x/oauth2+` is used in
-`+cloud.google.com/go+`:
-
-[source,bash]
-----
-grep -nr "golang.org/x/oauth2/google" $GOPATH/src/cloud.google.com/go
-
-/home/user/go/src/cloud.google.com/go/cmd/go-cloud-debug-agent/debuglet.go:38:   "golang.org/x/oauth2/google"
-/home/user/go/src/cloud.google.com/go/internal/testutil/context.go:26:   "golang.org/x/oauth2/google"
-/home/user/go/src/cloud.google.com/go/profiler/integration_test.go:30:   "golang.org/x/oauth2/google"
-/home/user/go/src/cloud.google.com/go/authexample_test.go:22:    "golang.org/x/oauth2/google"
-----
-
-We can see that it is not used in the `+cloud.google.com/go/compute/metadata+`
-subpackage. As a result we can split `+cloud.google.com/go/compute/metadata+`
-into a separate devel subpackage to resolve our cyclic dependency graph.
-
-To achieve this, we use multiple `+goipaths+` in the preamble:
-
-[source,rpm-spec]
-----
-%global goipaths0       cloud.google.com/go
-%global goipathsex0     cloud.google.com/go/compute
-
-%global goipaths1       cloud.google.com/go/compute
-----
-
-`+goipaths0+` will be the main package from which we exclude `+compute+`, and
-`+goipaths1+` will be the split package containing it.
-
-After building, we end up with two packages:
-
-* `+golang-cloud-google-devel-0.36.0-1.fc31.x86_64.rpm+`, which provides:
-+
-[source]
-----
-golang(cloud.google.com/go) = 0.36.0-1.fc31
-golang(cloud.google.com/go/asset/apiv1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/asset/v1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/bigquery) = 0.36.0-1.fc31
-golang(cloud.google.com/go/bigquery/datatransfer/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/bigquery/storage/apiv1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/bigtable) = 0.36.0-1.fc31
-golang(cloud.google.com/go/bigtable/bttest) = 0.36.0-1.fc31
-golang(cloud.google.com/go/bigtable/internal/cbtconfig) = 0.36.0-1.fc31
-golang(cloud.google.com/go/bigtable/internal/gax) = 0.36.0-1.fc31
-golang(cloud.google.com/go/bigtable/internal/option) = 0.36.0-1.fc31
-golang(cloud.google.com/go/bigtable/internal/stat) = 0.36.0-1.fc31
-golang(cloud.google.com/go/civil) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cloudtasks/apiv2beta2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cloudtasks/apiv2beta3) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/breakpoints) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/controller) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug/arch) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug/dwarf) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug/elf) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug/gosym) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug/local) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug/remote) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug/server) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug/server/protocol) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/debug/tests/peek) = 0.36.0-1.fc31
-golang(cloud.google.com/go/cmd/go-cloud-debug-agent/internal/valuecollector) = 0.36.0-1.fc31
-golang(cloud.google.com/go/container) = 0.36.0-1.fc31
-golang(cloud.google.com/go/container/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/containeranalysis/apiv1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/dataproc/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/dataproc/apiv1beta2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/datastore) = 0.36.0-1.fc31
-golang(cloud.google.com/go/debugger/apiv2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/dialogflow/apiv2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/dlp/apiv2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/errorreporting) = 0.36.0-1.fc31
-golang(cloud.google.com/go/errorreporting/apiv1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/expr/apiv1alpha1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/firestore) = 0.36.0-1.fc31
-golang(cloud.google.com/go/firestore/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/firestore/apiv1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/firestore/genproto) = 0.36.0-1.fc31
-golang(cloud.google.com/go/firestore/internal) = 0.36.0-1.fc31
-golang(cloud.google.com/go/functions/metadata) = 0.36.0-1.fc31
-golang(cloud.google.com/go/httpreplay) = 0.36.0-1.fc31
-golang(cloud.google.com/go/httpreplay/internal/proxy) = 0.36.0-1.fc31
-golang(cloud.google.com/go/iam) = 0.36.0-1.fc31
-golang(cloud.google.com/go/iam/admin/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/iam/credentials/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/btree) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/fields) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/leakcheck) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/optional) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/pretty) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/protostruct) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/testutil) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/trace) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/tracecontext) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/uid) = 0.36.0-1.fc31
-golang(cloud.google.com/go/internal/version) = 0.36.0-1.fc31
-golang(cloud.google.com/go/irm/apiv1alpha2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/kms/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/language/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/language/apiv1beta2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/logging) = 0.36.0-1.fc31
-golang(cloud.google.com/go/logging/apiv2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/logging/internal) = 0.36.0-1.fc31
-golang(cloud.google.com/go/logging/internal/testing) = 0.36.0-1.fc31
-golang(cloud.google.com/go/logging/logadmin) = 0.36.0-1.fc31
-golang(cloud.google.com/go/longrunning) = 0.36.0-1.fc31
-golang(cloud.google.com/go/longrunning/autogen) = 0.36.0-1.fc31
-golang(cloud.google.com/go/monitoring/apiv3) = 0.36.0-1.fc31
-golang(cloud.google.com/go/oslogin/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/oslogin/apiv1beta) = 0.36.0-1.fc31
-golang(cloud.google.com/go/profiler) = 0.36.0-1.fc31
-golang(cloud.google.com/go/profiler/mocks) = 0.36.0-1.fc31
-golang(cloud.google.com/go/profiler/proftest) = 0.36.0-1.fc31
-golang(cloud.google.com/go/pubsub) = 0.36.0-1.fc31
-golang(cloud.google.com/go/pubsub/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/pubsub/internal/distribution) = 0.36.0-1.fc31
-golang(cloud.google.com/go/pubsub/loadtest) = 0.36.0-1.fc31
-golang(cloud.google.com/go/pubsub/loadtest/pb) = 0.36.0-1.fc31
-golang(cloud.google.com/go/pubsub/pstest) = 0.36.0-1.fc31
-golang(cloud.google.com/go/redis/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/redis/apiv1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/rpcreplay) = 0.36.0-1.fc31
-golang(cloud.google.com/go/rpcreplay/proto/intstore) = 0.36.0-1.fc31
-golang(cloud.google.com/go/rpcreplay/proto/rpcreplay) = 0.36.0-1.fc31
-golang(cloud.google.com/go/scheduler/apiv1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/securitycenter/apiv1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/spanner) = 0.36.0-1.fc31
-golang(cloud.google.com/go/spanner/admin/database/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/spanner/admin/instance/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/spanner/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/spanner/internal/backoff) = 0.36.0-1.fc31
-golang(cloud.google.com/go/spanner/internal/testutil) = 0.36.0-1.fc31
-golang(cloud.google.com/go/speech/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/speech/apiv1p1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/storage) = 0.36.0-1.fc31
-golang(cloud.google.com/go/talent/apiv4beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/texttospeech/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/trace) = 0.36.0-1.fc31
-golang(cloud.google.com/go/trace/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/trace/apiv2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/translate) = 0.36.0-1.fc31
-golang(cloud.google.com/go/translate/internal/translate/v2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/videointelligence/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/videointelligence/apiv1beta1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/videointelligence/apiv1beta2) = 0.36.0-1.fc31
-golang(cloud.google.com/go/vision/apiv1) = 0.36.0-1.fc31
-golang(cloud.google.com/go/vision/apiv1p1beta1) = 0.36.0-1.fc31
-golang-cloud-google-devel = 0.36.0-1.fc31
-golang-cloud-google-devel(x86-64) = 0.36.0-1.fc31
-golang-ipath(cloud.google.com/go) = 0.36.0-1.fc31
-----
-* `+golang-cloud-google-compute-devel-0.36.0-1.fc31.x86_64.rpm+`, which
-  provides:
-+
-[source]
-----
-golang(cloud.google.com/go/compute/metadata) = 0.36.0-1.fc31
-golang-cloud-google-compute-devel = 0.36.0-1.fc31
-golang-cloud-google-compute-devel(x86-64) = 0.36.0-1.fc31
-golang-ipath(cloud.google.com/go/compute) = 0.36.0-1.fc31
-----
-
-We now have broken the cyclic dependency graph: `+golang.org/x/oauth2+` can now
-depend separately on `+golang-cloud-google-compute-devel+`.
-
-Here is the full example:
-
-.golang-cloud-google-go.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/golang-cloud-google-go.spec[]
-----
diff --git a/guidelines/modules/ROOT/pages/Golang_old.adoc b/guidelines/modules/ROOT/pages/Golang_old.adoc
deleted file mode 100644
index afdcd03..0000000
--- a/guidelines/modules/ROOT/pages/Golang_old.adoc
+++ /dev/null
@@ -1,744 +0,0 @@
-= Legacy Golang Packaging Guidelines
-:last-reviewed: 2019-06-19
-
-[IMPORTANT]
-====
-These guidelines were replaced by xref:Golang.adoc[a newer version].
-
-They exist as a historical reference for packages that don't follow the new guidelines yet.
-====
-
-This document details best practices for packaging Golang packages. Most of it
-is automated by an extensive use of macros.
-
-== go2rpm
-
-https://pagure.io/GoSIG/go2rpm/[go2rpm] is tool that automates many of these steps.
-It is advisable to try `+go2rpm import_path+` first
-before attempting to write a SPEC by hand.
-
-== Import Path
-
-In Golang, packages are referenced by full URLs. Since this URL is
-referenced in several places throughout the rpmspec, set the
-base import path as a global define at the top of the spec file
-
-[source,rpm-spec]
-----
-%global goipath     github.com/kr/pretty
-----
-
-All macros, including package name, source URL, will be computed from this
-value.
-
-[NOTE]
-====
-*Take the time to identify it accurately.* Changing it later will be
-inconvenient.
-
-* it may differ from the repository URL;
-* generally, the correct value will be the one used by the project in its
-  documentation, coding examples, and build assertions;
-* use the gopkg import path for all code states when a project uses it.
-
-If upstream confused itself after multiple forks and renamings, you will need
-to fix references to past names in the Go source files, unit tests included.
-Perform this fixing in `+%prep+`.
-====
-
-== Naming
-
-=== Source packages (src.rpm)
-
-* Golang source packages dedicated to providing code MUST be named after their
-  main import path.
-  This
-  process is automated by the `+%{goname}+` macro.
-  This macro will remove any capitalization, "go" keywords, and any duplication in
-  the import path.
-+
-For example:
-+
---
-** the import path `+github.com/kr/pretty+` will become
-   `+golang-github-kr-pretty+`
-** the import path `+github.com/DATA-DOG/go-txdb+` will become
-   `+golang-github-data-dog-txdb+`
-** the import path `+github.com/gopherjs/gopherjs+` will become
-   `+golang-github-gopherjs+`
---
-
-+
-The filename of spec MUST match the name of the package.
-
-+
-If you're not sure what will the name processed by the `+%{goname}+` macro be,
-simply build the SRPM with:
-
-
- fedpkg --release f31 srpm
-
-+
-The SRPM filename will be the one to use in your rpmspec and spec filename.
-
-* Source packages that provide a well-known application such as `+etcd+`
-  MUST be named after the application.
-  End users do not care about the language their applications are written in. But
-  do not name packages after an obscure utility binary that happens to be built by
-  the package.
-
-
-==== Implementation: `+%{gorpmname}+`
-
-`+%gometa+` uses the `+%{gorpmname}+` macro to compute the main `+%{goname}+`
-from `+%{goipath}+`.
-
-[NOTE]
-====
-*`+%{gorpmname}+` can produce collisions*
-
-`+%{gorpmname}+` tries to compute human-friendly and rpm-compatible naming from
-Go import paths. It simplifies them, removing redundancies and common
-qualifiers.
-As a result it is possible for two different import paths to produce the same
-result. In that case, feel free to adjust this result manually to avoid the
-collision.
-====
-
-=== Go code packages: `+%{goname}-devel+`
-==== In a source package dedicated to providing Go code
-
-Packages that ship Go code in `+%{goipath}+` should be named
-`+%{goname}-devel+`.
-If your source package is already named `+%{goname}+` then:
-
-[source,rpm-spec]
-----
-%package devel
-[…]
-%description devel
-[…]
-%files devel -f devel.file-list
-----
-
-This has been automated by the `+%{gopkg}+` and `+%{gopdevelkg}+` macros
-described in the <<Package metadata>> section below.
-
-==== In a another kind of source package
-
-If your source package is named something other than `+%{goname}+`, you SHOULD
-use:
-
-[source,rpm-spec]
-----
-%package -n %{goname}-devel
-[…]
-%description -n %{goname}-devel
-[…]
-%files -n %{goname}-devel -f devel.file-list
-----
-
-==== Separate code packages
-
-And, finally, if you wish to split the project Go code in multiple packages,
-you can compute the corresponding names with:
-
-[source,rpm-spec]
-----
-%global goname1 %gorpmname importpath1
-[…]
-%package -n %{goname1}-devel
-[…]
-%description -n %{goname1}-devel
-[…]
-%files -n %{goname1}-devel -f %{goname1}.file-list
-----
-
-See also the xref:Golang_advanced.adoc#_dealing_with_cyclic_dependencies[Dealing with cyclic dependencies]
-chapter.
-
-Do remember that for Go, each directory is a package. Never separate the .go
-files contained in a single directory in different packages.
-
-==== Import path compatibility packages: `+%{compat-%{oldgoname}-devel}+`
-
-When a project can be referenced under multiple import paths, due to forks,
-renamings, rehostings, organizational changes, or confusing project
-documentation, it is possible to generate compatibility sub-packages to
-connect code that uses one of the other import paths to the canonical one.
-
-The canonical import path SHOULD always be the one referenced in the project
-documentation.
-However some projects do not document import path changes, and rely on HTTPS
-redirections (for example https://github.com/docker/docker →
-https://github.com/moby/moby).
-Such a redirection is a sufficient indicator the canonical import path has
-changed (but please make sure with upstream).
-
-The new import path SHOULD be reflected in `+%{goipath}+` and compatibility
-import paths MUST be declared with the `+goaltipaths+` macro:
-
-[source,rpm-spec]
-----
-# A space-separated list of import paths to simulate.
-%global goaltipaths
-----
-
-For example, the Go library `+github.com/Sirupsen/logrus+` was renamed
-`+github.com/sirupsen/logrus+` and the documentation reflects this new import
-path.
-The packager SHOULD thus request a renaming of his package with a new import
-path and a compatibility import path:
-
-[source,rpm-spec]
-----
-%global goipath     github.com/sirupsen/logrus
-%global goaltipaths github.com/Sirupsen/logrus
-----
-
-If a project has gone through multiple rename, multiple compatibility import
-paths can be specified as well.
-
-[NOTE]
-====
-*Never defer renamings*
-
-Packagers MUST NOT use import path compatibility sub-packages to alias the
-canonical import path to one of the previous namings.
-Packagers MUST apply upstream renaming choices to the main `+%{goipath}+` spec
-variable and
-everything that derives from it, such as `+%{goname}+`.
-Deferred renamings introduce friction with upstream and other packagers.
-====
-
-=== Go binary packages
-
-The binaries produced by your rpmspec SHOULD generally be listed in the main
-package. However, if you want a more appropriate name or split binaries among
-different packages, you can create additional binary subpackage.
-Of course these package MUST NOT be noarch.
-
-For example we can create the package bbolt that will contain the binary
-of the same name:
-
-[source,rpm-spec]
-----
-%package -n bbolt
-[…]
-%description -n bbolt
-[…]
-%files -n bbolt
-%license LICENSE
-%{_bindir}/bbolt
-----
-
-== Versioning
-
-Many Go libraries do not use package versions or have regular releases and
-are instead maintained in public version control.
-In this case, follow the standard Fedora version conventions. This means that
-often Go packages will have a version number of `+0+` and a release number like
-`+0.10.20190319git27435c6+`.
-
-Most of this process is automated by macros so that you don't have to specify
-the release number yourself.
-
-You first specify either a Version, tag or commit in the header.
-
-[source,rpm-spec]
-----
-Version:
-%global tag
-%global commit
-----
-
-Then use the `+%gometa+` macro:
-
- %gometa
-
-The `+%gometa+` macro will automatically process the `+%{?dist}+` tag of the
-`+Release+` field to take into account the commit if any.
-
-[NOTE]
-====
-*Commits vs releases*
-
-You SHOULD package releases in priority.
-Please reward the projects that make an effort to identify stable code states.
-Only fall back to commits when the project does not release, when the release is
-more than six months old, or if
-you absolutely need one of the changes of a later commit.
-In the later cases please inform the project politely of the reason you needed
-to give up on their official releases.
-Promoting releases is a way to limit incompatible commit hell.
-====
-
-== Go Language Architectures
-
-To compile on various architectures, golang and gcc-go compilers are available.
-The golang compiler currently supports x86, x86_64, ppc64le, ppc64 (partially,
-see upstream issue#13192), s390x, armv7hl and aarch64.
-
-Binaries SHOULD set ExclusiveArch so that we only attempt to build packages on
-those arches.
-This is now automatically added by the `+%gometa+` macro by leveraging the
-`+%{golang_arches}+` macro.
-Packagers can exclude `+%ix86+`
-(see https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval[Changes/EncourageI686LeafRemoval])
-by passing `+-f+` to the `+%gometa+` macro.
-The `+-f+` flag tells `+%gometa+` to set `+ExclusiveArch: %{golang_arches_future}+`
-instead of `+ExclusiveArch: %{golang_arches}+`.
-`+%{golang_arches_future}+` includes the same architectures as
-`+{golang_arches}+` sans `+%ix86+`.
-
-== Dependencies
-
-Packages MUST have `+BuildRequires: go-rpm-macros+`.
-
-This is automated by the `+%gometa+` macro.
-
-
-=== Automatic Dependency Generation
-
-Most of the `+golang-*+` packages are source code only.
-The `+*-devel+` sub-package that includes the source code should explicitly have
-provides for the golang imports that it includes.
-These provides are automatically deduced from import paths.
-
-Binary builds that include these imports will use them in BuildRequires,
-for example:
-
-[source,rpm-spec]
-----
-BuildRequires: golang(github.com/gorilla/context)
-----
-
-===  Bundled or unbundled
-
-At the moment golang projects packaged in Fedora SHOULD be unbundled by
-default. It means projects are built from dependencies packaged in Fedora.
-
-For some project it can be reasonable to build from bundled dependencies.
-Every bundling needs a proper justification.
-
-
-=== BuildRequires
-
-The BuildRequires of the project contains the dependencies needed by unit tests
-and binaries.
-
-You can gather them manually with `golist`.
-For example:[[manual_br]]
-
-[source,bash]
-----
- export GOPATH=/home/user/go
- export GO111MODULE=off
- export goipath="github.com/sirupsen/logrus"
- go get $goipath
- (sort -u | xargs -I{} echo "BuildRequires:  golang({})") <<< "$(
-  golist --imported --package-path $goipath --skip-self
-  golist --imported --package-path $goipath --skip-self --tests
- )"
-----
-
-outputs:
-
-[source]
-----
-BuildRequires:  golang(github.com/stretchr/testify/assert)
-BuildRequires:  golang(github.com/stretchr/testify/require)
-BuildRequires:  golang(golang.org/x/crypto/ssh/terminal)
-----
-
-If automatic buildrequires are available on your build target, you can use
-the `+%go_generate_buildrequires+` macro in `+%generate_buildrequires+`:
-
-[source,rpm-spec]
-----
-%generate_buildrequires
-%go_generate_buildrequires
-----
-
-This macro leverages `+golist+` to gather build dependencies and tests
-dependencies from the package source.
-
-== Testing
-
-You MUST run unit tests.
-Due to the nature of Go development, especially the lack of use of semantic
-versioning, API breakages are frequent.These need to be detected early and dealt
-with upstream.
-
-Some tests may be disabled, especially the following kinds of unit tests are
-incompatible with a secure build environment such as mock:
-
-* tests that call a remote server or API over the Internet,
-* tests that attempt to reconfigure the system,
-* tests that rely on a specific app running on the system, like a database
-  or syslog server.
-
-If a test is broken for some other reason, you can disable it the same way.
-However, you SHOULD also report the problem upstream. Remember to trace in a
-comment why each check was disabled, with links to eventual upstream problem
-reports.
-
-== Walkthrough
-
-This chapter will present a typical Go spec file step by step, with comments
-and explanations.
-
-=== Spec preamble: `+%{goipath}+`, `+%{forgeurl}+` and `+%gometa+`
-
-==== Usual case
-
-A Go package is identified by its import path. A Go spec file will therefore
-start with the `+%{goipath}+` declaration. Don't get it wrong, it will control
-the behaviour of the rest of the spec file.
-
- %global goipath    google.golang.org/api
-
-If your package is hosted on a forge like GitHub, GitLab, Bitbucket or Pagure,
-the hosting of the Go package will be automatically deduced from this variable
-(typically by prefixing it with \https://). If that is not the case, you need
-to declare explicitly the hosting URL with the `+%{forgeurl}+` macro
-
- %global forgeurl    https://github.com/google/google-api-go-client
-
-The `+%{forgeurl}+` declaration is followed by either `+Version+`, `+commit+` or
-`+tag+`. Use the combination that matches your use-case.
-
- %global commit     2dc3ad4d67ba9a37200c5702d36687a940df1111
-
-[NOTE]
-====
-You can also define `+date+` to override the mtime of the Source archive.
-====
-
-Now that we have all the required variables, the `+%gometa+` macro can be run
-
- %gometa
-
-It will compute and set the following variables if they are not already set by
-the packager:
-
-goname::    an rpm-compatible package name derived from goipath
-gosource::  a URL that can be used as SourceX: value
-gourl::     a URL that can be used as URL: value
-
-It will delegate processing to the `+%forgemeta+` macro for:
-
-forgesource::       a URL that can be used as SourceX: value
-forgesetupargs::    the correct arguments to pass to `+%setup+` for this source
-used by `+%forgesetup+` and `+%forgeautosetup+`
-archivename::       the source archive filename, without extensions
-archiveext::        the source archive filename extensions, without leading dot
-archiveurl::        the URL that can be used to download the source archive,
-without renaming
-topdir::            the source archive top directory (can be empty)
-extractdir::        the source directory created inside `+%{_builddir}+` after
-using `+%forgesetup+`, `+%forgeautosetup+` or `+%{forgesetupargs}+`
-repo::              the repository name
-owner::             the repository owner (if used by another computed variable)
-shortcommit::       the commit hash clamping used by the forge, if any
-scm::               the scm type, when packaging code snapshots: commits or tags
-distprefix::        the prefix that needs adding to dist to trace non-release
-packaging
-
-Most of the computed variables are both overridable and optional.
-
-Now we can add the remaining elements of the preamble. First, we can define a
-multiline description block shared between subpackages:
-
-[source,rpm-spec]
-----
-%global common_description %{expand:
-cmux is a generic Go library to multiplex connections based on their payload.
-Using cmux, you can serve gRPC, SSH, HTTPS, HTTP, Go RPC, and pretty much any
-other protocol on the same TCP listener.}
-----
-
-This description MUST stay within 80 characters per line.
-
-[NOTE]
-====
-If you need specific devel summary and description, you can also define:
-
-- `+%global godevelsummary+`
-- `+%global godeveldescription+`
-====
-
-Then we MUST specify the license files that will be added to the devel
-subpackages:
-
-`+%global golicenses+`: A space-separated list of shell globs matching the
-project license files.
-
-And the possible documentation that SHOULD be included:
-
-`+%global godocs+`:  A space-separated list of shell globs matching the project
-documentation files. The Go rpm macros will pick up “.md” files by default
-without this.
-
-[NOTE]
-====
-You can also exclude files from `+%golicense+` and `+%godocs+` with:
-
-- `+%global golicensesex+`
-- `+%global godocsex+`
-
-For example you might want to exclude `+INSTALL*+` files from `+%godocs+` as
-these should not be provided.
-====
-
-=== Source package metadata: `+%{goname}+`, `+%{gourl}+` and `+%{gosource}+`
-
-We can declare the usual rpm headers, using the values computed by `+%gometa+`:
-
-[source,rpm-spec]
-----
-Name:      %{goname}
-# If not set before
-Version:
-Release:   1%{?dist}
-Summary:
-License:
-URL:       %{gourl}
-Source:    %{gosource}
-----
-
-You can replace them with manual definitions.
-For example, replace `+%{gourl}+` with the project homepage if it exists
-separately from the repository URL.
-Be careful to only replace `+%{go*}+` variables when it adds value to the
-specfile and you understand the consequences. Otherwise you will just add
-maintenance-intensive discrepancies in the distribution.
-
-=== BuildRequires
-
-If they are not automatically generated, you can now add the dependencies needed
-for package building and unit testings:
-
-[source,rpm-spec]
-----
-BuildRequires:  golang(github.com/stretchr/testify/assert)
-BuildRequires:  golang(github.com/stretchr/testify/require)
-BuildRequires:  golang(golang.org/x/crypto/ssh/terminal)
-----
-
-See <<manual_br,this section>> on how to get the BuildRequires list manually.
-
-=== Description
-
-Now add the main package description:
-
-[source,rpm-spec]
-----
-%description
-%{common_description}
-----
-
-=== Package metadata
-
-The process of declaring Go code packages has been automated with the
-`+%{gopkg}+` macro. It will automatically generate a `+%package+` and
-`+%description+` for all primary import paths and compatibility ones.
-
- %gopkg
-
-If you only need to generate Go devel subpackages without compat, use:
-
- %godevelpkg
-
-If necessary, you can then define one or multiple Go packages that will
-contain the binaries being built. See the previous <<Go binary packages>>
-section.
-
-=== %prep: `+%goprep+` , removing vendoring
-
-`+%goprep+` unpacks the Go source archives and creates the project “GOPATH” tree
-used in the rest of the spec file. It removes vendored (bundled) code:
-use the `+-k+` flag if you wish to keep this vendored code, and deal with the
-consequences in the rest of the spec.
-
- %goprep
-
-`+%goprep+` only performs basic vendoring detection. It will miss inventive ways
-to vendor code. Remove manually missed vendor code after the `+%goprep+` line.
-
-`+%goprep+` will not fix upstream sources for you. Since all the macro calls
-that follow `+%goprep+` assume clean problem-free sources, you need to correct
-them just after the `+%goprep+` line:
-
-* replace calls to deprecated import paths with their correct value
-* patch code problems
-* remove dead code (some upstreams deliberately ship broken source code in
-  the hope someone will get around to fix it)
-
-[NOTE]
-====
-You SHOULD send fixes and problem reports upstream. Any patch used
-SHOULD contain a link to an upstream bug report or merge request. At minimum,
-a comment SHOULD be added to explain the patch rationale.
-====
-
-When you package an import path, that participates in a dependency loop, you
-need bootstrapping to manage the initial builds:
-https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
-For Go code, that means your bootstrap section should:
-
-* remove unit tests that import other parts of the loop
-* remove code that imports other parts of the loop
-
-Sometimes one can resolve dependency loops just by splitting specific
-subdirectories in a separate -devel subpackage. See also
-xref:Golang_advanced.adoc#_dealing_with_cyclic_dependencies[Dealing with cyclic dependencies].
-
-=== Automatic BuildRequires
-
-If BuildRequires generator are supported, you can now add them to your build:
-
-[source,rpm-spec]
-----
-%generate_buildrequires
-%go_generate_buildrequires
-----
-
-=== Packaging a binary: the %build section
-
-If your package is a source package only, you can skip this `+%build+` section
-entirely.
-
-Otherwise, you first need to identify manually the project parts that can be
-built, and how to name the result.
-Practically, it’s any directory containing a main() Go section. Nice projects
-put those in `+cmd+` subdirectories named after the command that will be built,
-which is what we will document here, but it is not a general rule. Sometimes the
-whole `+%goipath+` builds as a single binary.
-
-[source,rpm-spec]
-----
-for cmd in cmd/* ; do
-  %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
-done
-----
-
-=== Installing the packages
-==== Source package installation
-
-If you package a library, `+%gopkginstall+` will perform installation steps
-for all primary import paths and compatibility ones.
-
- %gopkginstall
-
-If you only need to install Go devel subpackages without compat, use:
-
- %godevelinstall
-
-==== Binary package installation
-
-For binaries, we simply create the `+%{_bindir}+` directory in the buildroot
-and install the commands as executable in it:
-
-[source,rpm-spec]
-----
-install -m 0755 -vd                     %{buildroot}%{_bindir}
-install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/
-----
-
-[NOTE]
-====
-Be wary of command names which might already exist in Fedora. If you have
-any doubt, you can check if the command is already provided in Fedora:
-
-[source,shell]
-----
-dnf whatprovides --disablerepo="*" --enablerepo=rawhide "/usr/bin/$cmd"
-----
-
-If this is the case, use your best judgment to rename the command.
-====
-
-
-=== Running the unit tests: `+%gocheck+`
-
-As said before, you MUST run unit tests in `+%check+`:
-
- %gocheck
-
-However it is often necessary to disable some of them. You have 3 exclusion
-flags to do so:
-
-* `+-d <directory>+`:   exclude the files contained in `+<directory>+`
-                        non-recursively (subdirectories are not excluded)
-* `+-t <tree root>+`:   exclude the files contained in `+<tree root>+`
-                        recursively (subdirectories are excluded)
-* `+-r <regexp>+`:      exclude files matching `+<regexp>+`
-
-Remember to document why a test has been disabled.
-
-=== %files declaration
-==== When shipping source code
-
-The `+%gopkgfiles+` will process the file list produced in `+%install+` and add
-the necessary license and documentation files:
-
- %gopkgfiles
-
-==== When shipping binaries
-
-Binaries are usually shipped in the main package. This package MUST include
-legal files and documentation associated with those binaries.
-
-[source,rpm-spec]
-----
-%files
-%license LICENSE
-%doc cmd/foo/README.md
-%{_bindir}/*
-----
-
-== Examples
-
-=== Simple source package
-
-.golang-github-stretchr-testify.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/golang-github-stretchr-testify.spec[]
-----
-
-=== Handling package renames
-
-.golang-github-sirupsen-logrus.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/golang-github-sirupsen-logrus.spec[]
-----
-
-=== Simple binary package
-
-.golang-github-boltdb-bolt.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/golang-gopkg-square-jose-2.spec[]
-----
-
-== Additional resources
-
-=== Advanced uses cases
-
-** xref:Golang_advanced.adoc#_shipping_additional_files[Shipping additional files]
-** xref:Golang_advanced.adoc#_additional_header_declarations[Additional header declarations]
-** xref:Golang_advanced.adoc#_dealing_with_cyclic_dependencie[Dealing with cyclic dependencies]
-
-=== Additional annotated templates
-
-** xref:Golang_templates.adoc#_minimal_source_package[Minimal source package]
-** xref:Golang_templates.adoc#_full_source_package[Full source package]
-** xref:Golang_templates.adoc#_minimal_alternative_import_path[Minimal alternative import path]
-** xref:Golang_templates.adoc#_full_alternative_import_path[Full alternative import path]
-** xref:Golang_templates.adoc#_minimal_binary[Minimal binary]
-** xref:Golang_templates.adoc#_full_binary[Full binary]
-** xref:Golang_templates.adoc#_multi_package[Multi package]
-** xref:Golang_templates.adoc#_manual_package_deprecated[Manual package (deprecated)]
diff --git a/guidelines/modules/ROOT/pages/Golang_templates.adoc b/guidelines/modules/ROOT/pages/Golang_templates.adoc
deleted file mode 100644
index d3b4a15..0000000
--- a/guidelines/modules/ROOT/pages/Golang_templates.adoc
+++ /dev/null
@@ -1,66 +0,0 @@
-= Additional annotated templates
-:last-reviewed: 2019-03-22
-
-== Minimal source package
-
-.spectemplate-go-0-source-minimal.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/spectemplate-go-0-source-minimal.spec[]
-----
-
-== Full source package
-
-.spectemplate-go-1-source-full.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/spectemplate-go-1-source-full.spec[]
-----
-
-== Minimal alternative import path
-
-.spectemplate-go-2-alternative-import-path-minimal.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/spectemplate-go-2-alternative-import-path-minimal.spec[]
-----
-
-== Full alternative import path
-
-.spectemplate-go-3-alternative-import-path-full.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/spectemplate-go-3-alternative-import-path-full.spec[]
-----
-
-== Minimal binary
-
-.spectemplate-go-4-binary-minimal.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/spectemplate-go-4-binary-minimal.spec[]
-----
-
-== Full binary
-
-.spectemplate-go-5-binary-full.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/spectemplate-go-5-binary-full.spec[]
-----
-
-== Multi package
-
-.spectemplate-go-6-multi.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/spectemplate-go-6-multi.spec[]
-----
-
-== Manual package (deprecated)
-
-.spectemplate-go-7-manual.spec
-[source,rpm-spec]
-----
-include::{examplesdir}/golang/spectemplate-go-7-manual.spec[]
-----
diff --git a/guidelines/modules/ROOT/pages/Haskell.adoc b/guidelines/modules/ROOT/pages/Haskell.adoc
deleted file mode 100644
index 2a8b5ab..0000000
--- a/guidelines/modules/ROOT/pages/Haskell.adoc
+++ /dev/null
@@ -1,370 +0,0 @@
-= Haskell Packaging Guidelines
-
-This page documents the guidelines and conventions
-for packaging Haskell projects in Fedora.
-
-https://haskell.org/ghc[GHC] (Glasgow Haskell Compiler)
-is the current mainstream Haskell compiler.
-Most Haskell packages are released on
-https://hackage.haskell.org[Hackage]
-and use the
-https://www.haskell.org/cabal/[Cabal]
-package system.
-So the current guidelines largely focus
-on packaging for GHC using Cabal.
-
-== Spec file templates
-
-Spec files in line with these templates
-are generated automatically by the
-https://src.fedoraproject.org/rpms/cabal-rpm[cabal-rpm]
-packaging tool
-which also adds dependencies
-listed in the package's
-`+.cabal+` configuration file.
-Most packages should then build,
-though for some packages it may be necessary
-to specify some additional BuildRequires
-and/or Requires,
-and to check non-Haskell devel dependencies.
-
-Standardizing the packaging
-helps to lower the maintenance burden
-across Fedora's Haskell packages.
-
-There are three types of Haskell Cabal packages:
-library (Lib),
-binary only (Bin),
-and binary with library (BinLib):
-
-=== Library Only
-
-[source,RPMspec]
-----
-include::{examplesdir}/haskell-library-only.spec[]
-----
-
-=== Binary Only
-
-[source,RPMspec]
-----
-include::{examplesdir}/haskell-binary-only.spec[]
-----
-
-=== BinLib
-
-[source,RPMspec]
-----
-include::{examplesdir}/haskell-binary-library.spec[]
-----
-
-== Package Naming
-
-Haskell Bin packages should follow
-the usual Fedora Package Naming Guidelines
-for base package naming:
-i.e., follow the upstream name.
-Examples include projects like `+alex+`
-and `+cabal-install+`.
-
-The names of Haskell Lib packages,
-packaged for `+ghc+`,
-are prefixed by "ghc-".
-For example
-the Haskell aeson library package
-is named `+ghc-aeson+`,
-and the Haskell X11 library package
-is named `+ghc-X11+`, etc.
-
-Haskell BinLib packages
-should be named like a Bin package
-if the most important part they provide
-is an executable
-(eg `+hlint+`,
-`+ShellCheck+`,
-and `+pandoc+`),
-otherwise they should be named and packaged
-as a Lib package
-(eg `+ghc-hakyll+` (has a setup executable),
-`+ghc-vty+` (has demo executables))
-if they are actually a library
-that includes an helper executable
-or demo or minor utility.
-In this case typically
-the executable should live
-in the devel subpackage
-(or maybe the library base package
-if it is used at runtime).
-
-Note that
-having different Haskell source packages
-named "ghc-xyz"
-and "xyz"
-is not allowed
-since they would both correspond
-to the same upstream package
-named "xyz" on Hackage.
-
-BinLib packages
-should subpackage their libraries
-with naming following Lib packages.
-For example
-the `+pandoc+` BinLib package
-has library subpackages
-
-* `+ghc-pandoc+` for the shared library,
-* `+ghc-pandoc-devel+` for devel files and the static library,
-* `+ghc-pandoc-prof+` for the profiling static library,
-* `+ghc-pandoc-doc+` for the library's extracted development documentation.
-
-If a library is packaged for more than one Haskell compiler
-or interpreter,
-the base name should instead
-be prefixed with `+haskell+`,
-e.g. `+haskell-X11+`.
-Such a package would then have subpackages
-for each compiler and/or interpreter
-it is built for
-(e.g. `+ghc-X11+`,
-+hugs98-X11+`,
-etc).
-
-Package naming preserves case
-to follow the upstream naming conventions
-as closely as possible,
-including package dependencies.
-
-== Headers
-
-The macro `+pkg_name+`
-is used to carry the name of the upstream library package
-(i.e. without the Fedora "ghc-" prefix).
-It should be defined at the top of Lib
-and BinLib packages:
-
-`+%global pkg_name+`
-
-== Cabal Flags
-
-If needed
-Cabal flags for build options
-should be set by changing the package's `+.cabal+` file:
-this can usually be done with the `+cabal-tweak-flag+` script
-to avoid having to carry and maintain patches for this.
-
-For example
-`+cabal-tweak-flag systemlib True+`
-might enable a flag
-to use a system library dependency.
-
-`+%cabal_configure_options+`
-can be set to pass other options to Cabal.
-
-Modifying the `+.cabal+` file flags defaults
-allows packagers and tools like `+cabal-rpm+`
-to track actual package dependencies correctly.
-
-== Dependencies
-The `+cabal-tweak-dep-ver+` script
-can used to change version bounds of dependencies
-in the package's .cabal file:
-`+cabal-tweak-dep-ver deppkg oldbound newbound+`
-
-eg: `+cabal-tweak-dep-ver base '< 4.16' '< 4.17'+`
-
-Similarly `+cabal-tweak-drop-dep+`
-for dropping a redundant dependency
-(eg a compatibility dummy package).
-
-eg: `+cabal-tweak-drop-dep mtl-compat+`
-
-Spec file build dependencies
-are generated by the `+cabal-rpm+` packaging tool.
-
-Binary RPM dependencies for Haskell libraries
-are automatically generated at build-time
-by the `+ghc-deps.sh+` script.
-
-== Shared and static library linking
-
-GHC uses static libraries for linking by default.
-Lib and BinLib packages should provide static,
-shared,
-and profiling libraries:
-
-* the shared library lives in the base library package,
-
-* the static library and interface development files
-in the -devel subpackage,
-
-* and the profiling library
-and profiling interface files
-in the -prof subpackage.
-
-Since GHC assumes static versions of libraries are installed
-they need to be in the devel subpackage
-and it doesn't make sense to subpackage them.
-
-Executables in Bin and BinLib packages
-should be statically linked for portability.
-
-Due to how GHC links shared libraries using
-`+--no-as-needed+`
-they generate a lot of rpmlint
-`+E: undefined-non-weak-symbol+` errors,
-this is unfortunately currently expected
-(see these
-https://gitlab.haskell.org/ghc/ghc/-/issues/17157[upstream]
-https://gitlab.haskell.org/ghc/ghc/-/issues/23216[issues]).
-
-== RPM Macros
-
-The templates all have buildrequires for ghc-rpm-macros,
-which provides
-https://src.fedoraproject.org/rpms/ghc-rpm-macros/blob/master/f/macros.ghc[macros.ghc]
-to assist with packaging Haskell Cabal packages.
-
-....
-BuildRequires:  ghc-rpm-macros
-....
-
-The main commonly used macros are:
-
-* `+%ghc_bin_build+`
-* `+%ghc_lib_build+`
-* `+%ghc_bin_install+`
-* `+%ghc_lib_install+`
-
-They are used in the templates
-and explained in more detail below.
-
-== Bin packages
-
-Executables are statically linked
-to Haskell libraries by default.
-
-....
-%build
-%ghc_bin_build
-
-
-%install
-%ghc_bin_install
-....
-
-`+%ghc_bin_build+` is used to configure and build bin packages. It runs:
-
-* `+%cabal_configure+`: configure the package for building
-and dynamic linking.
-
-* `+%cabal build+`: builds the package.
-
-`+%ghc_bin_install+` is used to install bin packages. It runs:
-
-* `+%cabal_install+`: to install the package.
-
-== Lib and BinLib packages
-
-Devel subpackages need to setup some Requires:
-
-....
-%package -n ghc-%{pkg_name}-devel
-Summary:        Haskell %{pkg_name} library development files
-Requires:       ghc-compiler = %{ghc_version}
-Requires:       ghc-%{pkg_name} = %{version}-%{release}
-....
-
-Lib packages need to use `+%setup -n+`:
-
-....
-%prep
-%setup -q -n %{pkg_name}-%{version}
-....
-
-Both Lib and BinLib have:
-
-....
-%build
-%ghc_lib_build
-
-
-%install
-%ghc_lib_install
-....
-
-`+%ghc_lib_build+` is used to configure,
-build
-and generate documentation
-for Lib and BinLib packages.
-It runs:
-
-* `+%cabal_configure --ghc -p+`: configures the package
-for building with ghc
-and profiling.
-Libraries should build profiling versions
-of their static libraries.
-
-* `+%cabal build+`: builds the package.
-
-* `+%cabal haddock+`: generates HTML library documentation
-from the source code.
-
-** If documentation is failing to build for some reason,
-`+%ghc_lib_build_without_haddock+`
-can be used instead of
-`+%ghc_lib_build+`
-to disable haddock generation.
-
-`+%ghc_lib_install+` is used to install Lib and BinLib packages.
-It runs:
-
-* `+%cabal_install+`: installs the package
-without registering it in ghc-pkg.
-
-* `+%cabal_pkg_conf+`: creates ghc-pkg .conf metadata file
-for package installation time
-
-* `+%ghc_gen_filelists+`: generates rpm filelists.
-
-== Debuginfo
-
-Debuginfo is currently disabled for Haskell packages, because ghc's
-Dwarf output is not very useful. Stack backtraces can also be
-generated using profiling libraries.
-
-== Directories
-
-GHC libraries are installed under
-`+%ghclibdir/%{pkg_name}-%{version}+`:
-
-Library documentation lives under
-`+%ghclibdocdir/%{pkg_name}-%{version}+`.
-
-== File lists
-
-Filelists for shared and devel library subpackages
-are generated through
-`+%ghc_lib_install+`
-using the macro
-`+%ghc_gen_filelists+`.
-
-It generates the filelists
-`+ghc-%{pkg_name}.files+`,
-`+ghc-%{pkg_name}-devel.files+`,
-`+ghc-%{pkg_name}-prof.files+`,
-and `+ghc-%{pkg_name}-doc.files+`.
-
-== Compiling non-Cabal packages
-
-Packages compiling Haskell code without Cabal,
-i.e., directly with `+ghc+`
-or `+ghc --make+`,
-should use `+-O1+` optimization,
-like Cabal does by default.
-
-== References
-
-* https://hackage.haskell.org/package/cabal-rpm
-* https://src.fedoraproject.org/rpms/ghc-rpm-macros
-* https://wiki.debian.org/Haskell[Debian Haskell Group]
-* https://fedoraproject.org/wiki/Haskell_SIG[Fedora Haskell SIG]
diff --git a/guidelines/modules/ROOT/pages/Initial_Service_Setup.adoc b/guidelines/modules/ROOT/pages/Initial_Service_Setup.adoc
deleted file mode 100644
index 7872411..0000000
--- a/guidelines/modules/ROOT/pages/Initial_Service_Setup.adoc
+++ /dev/null
@@ -1,109 +0,0 @@
-= First-time Service Setup
-
-Many system services require some amount of initial setup before they can run properly for the first time. Common examples are the generation of private keys and certificates or a unique, system-specific identifier.
-
-Traditionally, this was done by RPM scriptlets as part of the installation or upgrade of a package. This was sensible for a time when the majority of installations were performed by attended or unattended installers (such as anaconda and kickstart).
-
-Today we see an increased reliance on generating virtual machine images for use in both traditional and cloud-computing environments. In those cases, having system-specific data created at package installation time is problematic. It means that the production of such images need to have significant care applied to remove any system-specific information about them and then additional tools written to apply the corrected information post-deployment. *The goal of this guideline is to ensure that if a system clean-up service such as virt-sysprep is run on the system and then the machine is rebooted, any service that requires first-time configuration will re-run it.* The mechanism by which we will accomplish this is to remove such first-time configuration from RPM scriptlets (e.g. `+%post+`) and instead execute this configuration as part of service startup with systemd.
-
-This guideline describes a mechanism that can be used for both traditional and cloud-based deployment styles.
-
-Note: this requirement can be waived if the equivalent functionality is incorporated as part of the service's own standard startup. These guidelines are meant to address services that require setup before the service can be started.
-
-== Defining System-Specific Setup
-
-A particular setup task is defined thusly: "Any action that must be performed on the system where the service will be run whose output is not identical for all systems running that service."
-
-Some non-exhaustive examples of system-specific configuration:
-
-* The SSH daemon generates a public/private host key
-* The mod_ssl httpd module creates a self-signed certificate for the machine's hostname
-* A remote logging service creates a UUID to represent this machine
-
-A few examples that should *not* be considered system-specific configuration:
-
-* Creating a service user and/or group. This is safe to copy to clones of the system.
-* Any content that is automatically re-generated by the service upon deletion.
-
-== Generating Self-Signed Certificates
-
-The sscg (Self-Signed Certificate Generator) tool should be used to generate self-signed certificates in a secure manner. It is present in all Fedora releases; online documentation can be found at https://github.com/sgallagher/sscg[1].
-
-=== More on self-signed certificates
-
-If your service makes use of the SSL/TLS protocol for transport security, your service will require a service certificate. Ideally the administrator deploying a new service should obtain an X.509 certificate from an appropriate Certificate Authority (CA), which should be from a globally operating CA (such as a commercial SSL certificate vendor) if your service will be available on the public Internet, or from a private CA (such as a domain controller CA) if your service will run inside an Intranet.
-
-However, it is often desirable to start using a self-signed certificate, which can be immediately created, and allows the administrator to immediately proceed doing the installation tasks. This document will explain how to obtain a self-signed certificate, but it is recommended that it gets replaced prior to public deployment.
-
-The disadvantage of self-signed certificates is that most client software (like web browsers) will reject them as untrusted, and if at all, will require the user to override and trust it explicitly. The way this can be done varies depending on the client software. It is easier to add a CA certificate to the system store and mark it as trusted.
-
-Therefore, instead of creating a self-signed certificate, we will create a temporary CA certificate and use it to sign the certificate used by the service. Afterwards we will delete the private key of the CA certificate, which will remove the ability to use it to create additional certificates. Afterwards we can import the CA certificate as trusted into the local system certificate store, and consequently every local client software that respects the system CA store will accept the service certificate as trusted. The sscg tool will handle all of this for you.
-
-== Common Guidelines
-
-For all system-specific cases, we will take advantage of systemd's https://www.freedesktop.org/software/systemd/man/systemd.service.html[service] functionality. Packagers will create a new service unit file for each service unit in their package that requires per-system configuration. This service unit will be named `+-init.service+` and installed to `+/usr/lib/systemd/system+`. For example, the `+tog-pegasus.service+` configuration unit would be `+/usr/lib/systemd/tog-pegasus-init.service+`.
-
-The contents of this service unit will be as follows:
-
-....
-[Unit]
-Description=One-time configuration for <servicename>
-
-ConditionPathExists=|!/path/to/generated/config
-ConditionPathExists=|!/path/to/other/generated/config (one or more lines optional)
-
-[Service]
-Type=oneshot
-RemainAfterExit=no
-
-ExecStart=/path/to/config/script
-....
-
-The syntax for `+ConditionPathExists=+` uses the ! to indicate negation (the file is not present). The | is used to create an OR logical pairing (resulting in the lack of ANY of these files causing the configuration to be run). Those are called "triggering" conditions, for full explanation see https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionArchitecture=[systemd.unit(5)]. The `+/path/to/config/script+` can be any executable script or binary that will generate the initial configuration needed by this service. It *must* generate the files tested by `+ConditionPathExists+`. If the script is a single command, it can be run directly by this service unit. If it needs to run multiple commands, it is recommended to create a script file in the package's `+/usr/libexec/+` directory and execute that.
-
-To use `+tog-pegasus.service+` as an example:
-
-....
-[Unit]
-Description=One-time configuration for tog-pegasus
-
-ConditionPathExists=|!/etc/Pegasus/server.pem
-ConditionPathExists=|!/etc/Pegasus/file.pem
-ConditionPathExists=|!/etc/Pegasus/client.pem
-
-[Service]
-Type=oneshot
-RemainAfterExit=no
-
-ExecStart=/usr/bin/sscg --package tog-pegasus --ca-file /etc/Pegasus/client.pem --cert-file /etc/Pegasus/server.pem --cert-key-file /etc/Pegasus/file.pem
-....
-
-The `+ExecStart+` command may do anything, so long as it returns 0 on success. In this case, we are generating a self-signed certificate for the service to use.
-
-Packagers will also need to update their primary service unit to require this one and run after it:
-
-....
-[Unit]
-...
-Requires=<service>-init.service
-After=<service>-init.service
-....
-
-To continue the `+tog-pegasus.service+` example:
-
-....
-[Unit]
-Description=OpenPegasus CIM Server
-After=slpd.service
-
-Requires=tog-pegasus-init.service
-After=tog-pegasus-init.service
-
-[Service]
-Type=forking
-ExecStart=/usr/sbin/cimserver
-PIDFile=/var/run/tog-pegasus/cimserver.pid
-
-[Install]
-WantedBy=multi-user.target
-....
diff --git a/guidelines/modules/ROOT/pages/Java.adoc b/guidelines/modules/ROOT/pages/Java.adoc
deleted file mode 100644
index 20cb7c8..0000000
--- a/guidelines/modules/ROOT/pages/Java.adoc
+++ /dev/null
@@ -1,166 +0,0 @@
-= Java Packaging Guidelines
-:last-reviewed: 2022-07-01
-
-This page represents Fedora guidelines
-for packaging libraries and applications
-written in Java and related languages
-that use the Java Virtual Machine as a 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://docs.fedoraproject.org/en-US/java-packaging-howto/[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.
-
-Fedora Java packaging is originally based on the https://web.archive.org/web/20191223234327/http://www.jpackage.org/[JPackage Project] standards.
-Over time, we have diverged in packaging tools in most areas
-but we mostly keep backward compatibility with older packages
-that make use of JPackage standards.
-
-== Package naming
-
-Packages MUST follow the standard Fedora xref:Naming.adoc[package naming guidelines].
-
-Java API documentation MUST be placed into a sub-package called `+%{name}-javadoc+`.
-
-== Release tags
-
-Packages MUST follow the standard Fedora xref:Versioning.adoc[package versioning guidelines].
-
-== Architecture support
-
-The system JDK / JRE might not be available on all architectures
-that are supported by any given Fedora release.
-
-For this reason, all Java packages MUST contain an `+ExclusiveArch+` tag:
-
-* Packages that build only `+noarch+` sub-packages
-  MUST use `+ExclusiveArch: %{java_arches} noarch+`.
-* Packages that include architecture-dependent build artifacts (i.e. <<JNI>> modules)
-  MUST use `+ExclusiveArch: %{java_arches}+`.
-
-The `+%{java_arches}+` macro contains a list of all the architectures
-where the system JRE / JDK is available and is defined on all Fedora releases.
-
-== Pre-built dependencies
-
-Packages MUST follow the standard Fedora xref:what-can-be-packaged.adoc#prebuilt-binaries-or-libraries[dependency bundling guidelines].
-
-In particular, `+*.class+` and `+*.jar+` files from upstream releases
-MUST NOT be used during build of Fedora packages
-and they MUST NOT be included in binary RPM.
-
-== JAR file installation
-
-The following applies to all JAR files
-except <<JNI,JNI-using JAR files>> and application-specific JAR files
-(i.e., JAR files that can only reasonably be used as part of an application
-and therefore constitute application-private data).
-
-=== Split JAR files
-
-If a project offers the choice of packaging it
-as a single monolithic JAR or as several separate JARs,
-the split packaging SHOULD be preferred.
-
-=== Installation directory
-
-* All architecture-independent JAR files MUST go into `+%{_javadir}+` or its subdirectory.
-* For installation of architecture dependent JAR files, see <<JNI>>.
-
-=== Filenames
-
-* If the package provides a *single* JAR file installed filename SHOULD be `+%{name}.jar+`.
-* If the package provides *multiple* JAR files, they SHOULD be installed in a `+%{name}+` subdirectory.
-* Versioned JAR files (`+*-%{version}.jar+`) MUST NOT be installed unless the package is a compatibility package.
-* Packages MAY provide alternative filenames, as long as they do not conflict with other packages.
-
-== BuildRequires and Requires
-
-Java packages MUST BuildRequire their respective build system (or a versioned binding thereof):
-
-* `+BuildRequires: maven-local+` or `+maven-local-openjdk${N}+` for packages built with Maven
-* `+BuildRequires: javapackages-local+` or `+javapackages-local-openjdk${N}+` for packages not built with Maven
-
-Java applications SHOULD have `+Requires+` on an appropriate Java runtime package:
-
-* `+java-headless+` for applications not requiring graphical interface
-* `+java+` for applications requiring graphical interface
-* `+java-devel+` for applications requiring additional content related to Java development
-
-== Javadoc installation
-
-* JavaDoc documentation MAY be generated.
-* If javadoc documentation is generated,
-  it MUST be installed into a directory of `+%{_javadocdir}/%{name}+`
-  as part of the `+-javadoc+` subpackage.
-* Directory or symlink `+%{_javadocdir}/%{name}-%{version}+` SHOULD NOT exist.
-* The javadoc subpackage MUST be declared `+noarch+`, even if main package is architecture specific.
-
-== No class-path in MANIFEST.MF
-
-JAR files MUST NOT include a `+class-path+` entry
-in their `+META-INF/MANIFEST.MF+` file.
-
-== Hardcoded paths
-
-Packages MUST NOT hardcode paths to JAR files they use.
-When a package needs to reference a JAR file,
-the packager SHOULD use one of tools
-that are designed for locating JAR files in the system.
-
-== Maven pom.xml files
-
-If upstream project is shipping Maven `+pom.xml+` files,
-these MUST be installed.
-Additionally, the package MUST install a mapping between the upstream artifact
-and the filesystem by using the `+%mvn_install+` macro.
-
-If upstream project does not ship Maven `+pom.xml+` file,
-the official https://mvnrepository.com/[maven repository] should be consulted
-and if the project publishes `+pom.xml+` files there,
-they SHOULD be included.
-
-If modifications to Maven pom.xml files are needed,
-the `+%pom_*+` family of macros SHOULD be used.
-
-== Wrapper Scripts
-
-Applications wishing to provide a convenient method of execution
-SHOULD provide a wrapper script in `+%{_bindir}+`.
-Packages SHOULD use `+%jpackage_script+` to create these wrapper scripts.
-
-== Compatibility packages
-
-In certain cases it might be necessary to create compatibility packages
-that provide older API/ABI level of the same library.
-However, creating these compatibility packages is strongly discouraged.
-
-To standardize and simplify packaging of such compatibility packages,
-the following rules apply:
-
-* Compatibility packages MUST be named in the same way as the original package
-  except the addition of the version to the package's name.
-* Any JAR and POM files MUST be versioned, as well.
-
-[#JNI]
-== Packaging JAR files that use JNI
-
-=== Applicability
-
-Java programs that wish to make calls into native libraries
-do so via the Java Native Interface (JNI).
-A Java package uses JNI if it contains a .so file.
-Note that this file can be embedded within JAR files themselves.
-
-=== Guideline
-
-JNI packages MUST follow guidelines of ordinary Java packages,
-with these exceptions:
-
-* JAR files using JNI or containing JNI shared objects themselves
-  MUST be placed in `+%{_jnidir}+`,
-  but MAY be symlinked to `+%{_libdir}/%{name}+`.
-* JNI shared objects MUST be placed in `+%{_libdir}/%{name}+`.
-
diff --git a/guidelines/modules/ROOT/pages/JavaScript.adoc b/guidelines/modules/ROOT/pages/JavaScript.adoc
deleted file mode 100644
index 8673aa5..0000000
--- a/guidelines/modules/ROOT/pages/JavaScript.adoc
+++ /dev/null
@@ -1,163 +0,0 @@
-= JavaScript Packaging Guidelines
-:last-reviewed: 2019-01-17
-
-== Overview
-
-JavaScript code used for the web needs special consideration
-to ensure that it meets the high standards expected of all code shipped by Fedora,
-while still being useful
-and complying with conventions already used on millions of websites.
-Additionally, certain libraries typically used on the web
-can also be useful in a server-side context
-(by nodejs or rubygem-execjs),
-so it's important to package JavaScript so
-it meets the standards required of locally executed code as well.
-
-Please note that this section really only applies to JavaScript libraries
-intended for use on the web.
-Server-side JavaScript runtimes like
-Node.js xref:Node.js.adoc[have their own guidelines],
-and software like GNOME which embeds JavaScript for extensions
-have their own directories and policies as well.
-
-Packages containing JavaScript should make the best effort to regenerate any precompiled/minimized JS wherever possible,
-as this leads to more maintainable packages.
-Where this would result in a significant hardship,
-the bundled pregenerated JS may be shipped with a specfile comment explaining the decision.
-This does not eliminate the requirement to validate licenses of bundled code.
-
-== Naming Guidelines
-
-The name of a JavaScript library package MUST start with
-`+js-+` then the upstream name. For example: `+js-jquery+`.
-
-== BuildRequires
-
-To ensure the presence of the necessary RPM macros,
-all packages that provide JavaScript in `+%{_jsdir}+` MUST have:
-
-    BuildRequires: web-assets-devel
-
-== Requires
-
-To ensure the availability of the necessary directories,
-all packages that provide JavaScript in `+%{_jsdir}+` MUST have:
-
-    Requires: web-assets-filesystem
-
-JavaScript packages MUST NOT have Requires on any
-HTTP daemon-specific configuration package,
-such as `+web-assets-httpd+`,
-since they could be used by any HTTP daemon.
-
-== RPM Macros
-
-|===
-|Macro |Normal Definition |Notes
-
-|`+%{_jsdir}+` |`+%{_datadir}/javascript+` |The directory where JavaScript libraries are stored
-|===
-
-== Install Location
-
-* If a JavaScript library can be executed locally
-  or consists purely of JavaScript code,
-  it MUST be installed into a subdirectory of `+%{_jsdir}+`.
-
-* If a package contains JavaScript code,
-  but is never useful outside the browser
-  (e.g. if it is some sort of HTML user interface library)
-  it may instead install to `+%{_assetdir}+`.
-  For more information, see xref:Web_Assets.adoc[the Web Assets guidelines].
-
-* If a package contains JavaScript code
-  that is only used as part of a web application,
-  and it is not useful to any other applications whatsoever,
-  it may continue to ship that code along with the application.
-  However, that does not absolve it from complying
-  with the rest of these guidelines.
-
-* If a package contains JavaScript code
-  that is not useful on the web,
-  but only in locally run software
-  (e.g. xref:Node.js.adoc[Node.js] or GNOME shell extensions),
-  it should use the appropriate directory for its runtime,
-  not `+%{_jsdir}+`.
-
-== Server Location
-
-JavaScript code is included as part of the general xref:Web_Assets.adoc[Web Assets framework].
-Therefore, `+%{_jsdir}+` is available on Fedora-provided web servers
-by default at `+/_sysassets/javascript/+`.
-
-For instance, jQuery may be installed in `+%{_jsdir}/jquery/jquery-min.js+`,
-so web applications that need to use it can simply include this HTML tag:
-
-----
-<script type="text/javascript" src="/_sysassets/javascript/jquery/jquery-min.js"></script>;
-----
-
-Regardless, web applications may want to make
-subdirectories of `+%{_jsdir}+` available
-under their own directory via aliases or symlinks
-for compatibility purposes
-or to eliminate needless deviation from upstream.
-
-== Compilation/Minification
-
-If a JavaScript library typically is shipped as minified or compiled code,
-it MUST be compiled or minified as part of the RPM build process.
-Shipping pre-minified or pre-compiled code is unacceptable in Fedora.
-
-The compiler or minifier used by upstream
-should be used to compile or minify the code.
-If the minifier used by upstream is unable to be included in Fedora,
-an alternative minifier may be used.
-See https://fedoraproject.org/wiki/JavaScript/Minification_Issues[this page]
-for a list of known problem areas and suggestions for workarounds.
-
-Additionally, the uncompiled/unminified version MUST be included
-alongside the compiled/minified version.
-
-Minified JavaScript is not useful for JavaScript run locally,
-as the entire point of minification is to reduce HTTP transfer times.
-Therefore, JavaScript not intended for the web
-(e.g. for Node.js or GNOME Shell extensions)
-MUST NOT be minified.
-
-== Bundling of other Libraries
-
-It is common for a single minified JavaScript file
-to contain bundled code from other JavaScript libraries.
-JavaScript is treated no differently
-than other libraries in this respect,
-so the
-xref:index.adoc#bundling[Bundling Guidelines].
-MUST still be followed.
-
-== Wrappers for Other Languages or Environments
-
-Sometimes there may exist a simple wrapper
-from a foreign language
-(like Ruby via rubygem-execjs or Java via rhino)
-or server-side JavaScript environment
-(like Node.js)
-to a pure JavaScript library.
-Such packages should delete the bundled library code
-and instead point to and Require the code provided
-by the primary Fedora package for that library.
-
-== Node.js Modules that contain browser/pure-JS components
-
-Some Node.js modules include parts that can be used in the browser
-or by other server-side JavaScript engines.
-Such packages should be shipped as one SRPM that contains two packages:
-
-* One `+js-foo+` package that contains
-  the pure JavaScript portion, following these guidelines.
-
-* One `+nodejs-foo+` package that contains
-  the Node.js module portion,
-  following the xref:Node.js.adoc[Node.js guidelines].
-  This may symlink to the necessary files or directories
-  of the `+js-foo+` package.
diff --git a/guidelines/modules/ROOT/pages/KDEPackaging.adoc b/guidelines/modules/ROOT/pages/KDEPackaging.adoc
deleted file mode 100644
index e4484fd..0000000
--- a/guidelines/modules/ROOT/pages/KDEPackaging.adoc
+++ /dev/null
@@ -1,65 +0,0 @@
-= KDE Packaging
-
-:last-reviewed: 2024-01-02
-
-This document outlines the best practices for packaging software using the KDE frameworks, for use in Fedora.
-
-== Build Dependencies
-
-If using cmake, the following BuildRequires are a *MUST*:
-
-[source, rpm-spec]
-----
-BuildRequires: cmake
-BuildRequires: gcc-c++
-BuildRequires: kf6-rpm-macros
-----
-
-`kf6-rpm-macros` needs to be changed to `kf5-rpm-macros` if building for Plasma 5 instead of Plasma 6.
-
-== Available Macros
-
-The following macros are used in the building of KDE packages. Note that the version of macros (i.e. `%cmake_kf5` and `%cmake_kf6`) can be changed depending on which version of Plasma you are building for.
-
-`+%cmake_kf6+`::
-Not unlike `+%cmake+`, this macro defines CFLAGS, LDFLAGS, etc. and calls `+%__cmake+`
-with appropriate parameters
-(`+-DCMAKE_INSTALL_PREFIX:PATH=/usr+` and such), but with additional KDE-specific flags and parameters.
-You can pass `+-Doption=value+` to this macro
-in order to set options for the buildsystem.
-
-`+%stable_kf6+`::
-Used in the package's source links, if the package is released on the official KDE download server. Outputs either `stable` or `unstable` depending on the version of the package.
-
-Here's an example of how it would look like:
-----
-Source0: http://download.kde.org/%{stable_kf6}/release-service/%{version}/src/%{name}-%{version}.tar.xz
-----
-
-`+%find_lang_kf6+`::
-This macro is sometimes used instead of `+%find_lang+` in packages using language files ending in `_qt.qm`.
-
-[#kde-file-macros]
-== Macros for paths set and used by build systems
-
-The following table lists macros which are widely used in fedora `.spec` files. Those macros are provided by the `kf5-rpm-macros` (For Plasma 5) and `kf6-rpm-macros` (For Plasma 6) packages.
-
-For Plasma 5, the following macros can simply have their version number changed to reflect the Plasma 5 version (For example, `+%{_kf6_datadir}+` would become `+%{_kf5_datadir}+`).
-
-[cols="20%m,30%m,50%",options="header"]
-|=================================
-| macro                | definition                  | comment
-| +%{_kf6_prefix}+     | +%{_prefix}+                |
-| +%{_kf6_archdatadir}+| +%{_qt6_archdatadir}+       | default: `/usr/lib64/qt6`
-| +%{_kf6_bindir}+     | +%{_kf6_prefix}+/bin        |
-| +%{_kf6_datadir}+    | +%{_datadir}+               | default: `/usr/share`
-| +%{_kf6_includedir}+ | +%{_includedir}+/KF6        | default: `/usr/include/KF6`
-| +%{_kf6_libdir}+     | +%{_exec_prefix}/%{_lib}+   | default: `+/usr/%{_lib}+`
-| +%{_kf6_libexecdir}+ | +%{_libexecdir}+/kf6        | default: `/usr/libexec/kf6`
-| +%{_kf6_metainfodir}+| +%{_metainfodir}+           | default: `/usr/share/metainfo`
-| +%{_kf6_qtplugindir}+| +%{_qt6_plugindir}+         | default: `+/usr/%{_lib}/qt6/plugins+`
-| +%{_kf6_plugindir}+  | +%{_qt6_plugindir}+/kf6     | default: `+/usr/%{_lib}/qt6/plugins/kf6+`
-| +%{_kf6_sysconfdir}+ | +%{_sysconfdir}+            | default: `/etc`
-| +%{_kf6_mandir}+     | +%{_kf6_datadir}+/man       | default: `/usr/share/man`
-| +%{_kf6_qmldir}+     | +%{_kf6_archdatadir}+/qml   | default: `/usr/lib64/qt6/qml`
-|=================================
diff --git a/guidelines/modules/ROOT/pages/Langpacks.adoc b/guidelines/modules/ROOT/pages/Langpacks.adoc
deleted file mode 100644
index a3abafb..0000000
--- a/guidelines/modules/ROOT/pages/Langpacks.adoc
+++ /dev/null
@@ -1,43 +0,0 @@
-= Language packages
-
-The idea behind "langpacks" is to separate translations or language specific content into subpackages in the case that the size of the files is huge or the package is part of a core image that should be minimal.
-
-Subpackages that exist solely to contain additional language translations or content must be named in the form -langpack-, where is the name of the package that the langpacks belong to and is a valid language code from _/usr/share/xml/iso-codes/iso_639_3.xml_ or from _/usr/share/i18n/locales/_. Specifically, the langcode value used in the package name must agree with the langcode identifier used in the directory path by upstream for the translation or language files.
-
-The langpack ecosystem does not need any procedural logic in the form of plugins. Instead it takes advantage of the weak and rich dependency features provided by RPM. The necessary dependencies are computed by the package manager (DNF or PackageKit) so it is essential to include the following `+Supplements:+` tag relation in the langpack package definition in the spec file:
-
-`+Supplements: (%{name} = %{version}-%{release} and langpacks-<locale>)+`
-
-== Example
-
-Suppose you have a package with following spec file:
-
-`+Name: php-horde-Horde-Perms+` +
-`+...+` +
-`+%files -f Horde_Perms.lang+` +
-`+/usr/share/pear-data/Horde_Perms/locale/+` +
-`+...+`
-
-In order to create langpacks for each language (_/usr/share/pear-data/Horde_Perms/locale//LC_MESSAGES/Horde_Perms.mo_ translations), you would need to define a new subpackage for each package. The snippet below shows a macro for automating the definition of langpacks, along with the definition of langpacks for _bs_ and _cs_ languages. This would replace the lines shown above. Note that this macro definition is specific to the example package; you will need to modify it as appropriate for your package.
-
-`+Name: php-horde-Horde-Perms+` +
-`+...+` +
- +
-`+%define lang_subpkg() \+` +
-`+%package langpack-%{1}\+` +
-`+Summary:       %{2} language data for %{name}\+` +
-`+BuildArch:     noarch\+` +
-`+Requires:      %{name} = %{version}-%{release}\+` +
-`+Supplements:   (%{name} = %{version}-%{release} and langpacks-%{1})\+` +
-`+\+` +
-`+%description langpack-%{1}\+` +
-`+%{2} language data for %{name}.\+` +
-`+\+` +
-`+%files langpack-%{1}\+` +
-`+%{_datadir}/pear-data/Horde_Perms/locale/%{1}/+` +
-`+ %lang_subpkg bs Bosnian+` +
-`+%lang_subpkg cs Czech+` +
-`+...+` +
- +
-`+%files+` +
-`+...+`
diff --git a/guidelines/modules/ROOT/pages/LibreOfficeExtensions.adoc b/guidelines/modules/ROOT/pages/LibreOfficeExtensions.adoc
deleted file mode 100644
index 8fb57fc..0000000
--- a/guidelines/modules/ROOT/pages/LibreOfficeExtensions.adoc
+++ /dev/null
@@ -1,21 +0,0 @@
-= LibreOffice extension rpm guidelines
-
-1.  Extensions *Must* be installed unpacked under %\{_libdir}/libreoffice/share/extensions. These are termed bundled extensions. Extensions should not be installed as shared extensions i.e. via unopkg --shared +
-2.  An extension should normally just be able to Require: an appropriate LibreOffice component e.g. libreoffice-core, without a specific n-v-r as extensions use the stable UNO ABI which rarely changes, and then only to add extra APIs. So unless you require a specific feature of a LibreOffice release there is no need to require a specific n-v-r and force a rebuild on every n-v-r of libreoffice. +
-3.  Extensions *Must* be named libreoffice-FOO. +
-4.  Extensions are similar to e.g. xorg video drivers in that there exist proprietary or binary only extensions, but of course normal Fedora rules apply to what extensions can be packaged, i.e. see normal packaging licensing etc. rules. The license *Must* be acceptable, and the package *Must* be built from source. +
-5.  Extensions can be written in any language that has an uno binding, e.g. C++, python, java or StarBasic. Consider the additional packaging guidelines of the language that the extension is written in if such guidelines exists. +
-6.  Many extensions are actually architecture independent, but cannot be noarch packages due to libreoffice limitations. Such packages will generate empty debuginfo sub-packages. If this is the case, add '%global debug_package %\{nil}' to the package.
-
-.. +
-   An example is... +
-
-....
-%global extname writer2latex
-Name:     libreoffice-%{extname}
-Requires: libreoffice-core
-
-%install
-install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extname}
-unzip -q target/lib/%{extname}.oxt -d $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extname}
-....
diff --git a/guidelines/modules/ROOT/pages/LicensingGuidelines.adoc b/guidelines/modules/ROOT/pages/LicensingGuidelines.adoc
deleted file mode 100644
index 42400ff..0000000
--- a/guidelines/modules/ROOT/pages/LicensingGuidelines.adoc
+++ /dev/null
@@ -1,179 +0,0 @@
-= Licensing Guidelines
-
-== Fedora Licensing
-
-The goal of the Fedora Project is
-to work with the Linux community to create a complete,
-general purpose operating system
-exclusively from free and open source software.
-
-All software in Fedora must be under licenses
-that have been determined to be
-https://docs.fedoraproject.org/en-US/legal/license-approval/[allowed for Fedora].
-This criteria is based on the licenses approved by the
-https://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses[Free Software Foundation],
-https://opensource.org/licenses/[OSI]
-and consultation with Red Hat Legal.
-
-For more details on the criteria for allowed
-and not-allowed licenses, processes related to licensing,
-or other guidance related to Fedora licensing,
-see xref:legal::index.adoc[Licensing in Fedora].
-
-The information here provides guidance
-on how to add license text in `+%license+`
-and how to populate the `+License:+` field of
-spec files for Fedora packages.
-
-== License Text
-
-If the source package includes the text of the license(s) in its own file,
-then that file,
-containing the text of the license(s) for the package
-must be included in the `+%files+` list
-flagged with the `+%license+` directive.
-
-Note that the path so flagged can be either relative or absolute.
-For relative paths, RPM will automatically copy them
-from the source directory into a subdirectory of
-`+%_defaultlicensedir+` (`+/usr/share/licenses+`).
-For absolute paths, RPM will simply tag the file in the final package
-as being a license file.
-
-Note also that it is acceptable for license files to be so flagged
-in a list which is generated programmatically
-and included using `+%files -f+`.
-This tagging is often done automatically by macros
-and not directly visible to the packager.
-What is important is not the visible presence of the `+%license+` directive
-but instead that all relevant license files included in a package appear
-when using `+rpm -q --licensefiles+`.
-
-If the source package does not include the text of the license(s),
-the packager should contact upstream
-and encourage them to correct this mistake.
-
-In cases where the upstream has chosen a license that requires
-that a copy of the license text be distributed
-along with the binaries and/or source code,
-but does not provide a copy of the license text
-(in the source tree, or in some rare cases, anywhere),
-the packager should do their best to point out this confusion to upstream.
-This sometimes occurs when an upstream project's only reference to a license
-is in a README
-(where they simply say "licensed under the FOO license"),
-on their website,
-or when they simply do not check a copy of the license into their Source tree.
-Packagers should point out to upstream
-that by not including a proper full license text,
-they are making it difficult or impossible
-for anyone to comply with their desired license terms.
-
-However, in situations where upstream is unresponsive, unable, or unwilling
-to provide proper full license text as part of the source code,
-and the indicated license requires that the full license text be included,
-Fedora Packagers must either:
-
-* Include a copy of what they believe the license text is intended to be,
-as part of the Fedora package in `+%license+`,
-in order to remain in compliance.
-It is worth noting that this may place some additional risk on the packager,
-however, Fedora believes that this risk is minimized
-by the fact that if the upstream disagrees
-with what we have distributed as the full license text,
-they can easily remedy this by making full license text available
-in the source code.
-Packagers who choose to do this should ensure
-that they have exhausted all attempts to work with upstream
-to include the license text as part of the source code,
-or at least, to confirm the full license text
-explicitly with the upstream,
-as this minimizes the risk on the packager.
-Packagers may also take copies of license texts
-from reliable and canonical sources
-(such as the original license text from the license steward,
-Fedora licenses page,
-the FSF licenses page,
-or the OSI license list),
-whenever possible.
-
-* Choose not to package that software for Fedora.
-
-It is important to reiterate
-that in situations where the indicated license does not imply a requirement
-that the license be distributed along with the source/binaries,
-Fedora packagers are NOT required to manually include the full license text
-when it is absent from the source code,
-but are still encouraged to point out this issue to upstream
-and encourage them to remedy it.
-
-[#subpackage-licensing]
-=== Subpackage Licensing
-
-If a subpackage is dependent
-(either implicitly or explicitly)
-upon a base package
-(where a base package is defined as a resulting binary package
-from the same source RPM
-which contains the appropriate license texts as `+%license+`),
-it is not necessary for that subpackage
-to also include those license texts as `+%license+`.
-
-However, if a subpackage is independent of any base package
-(it does not require it, either implicitly or explicitly),
-it must include copies of any license texts
-(as present in the source)
-which are applicable to the files contained within the subpackage.
-
-=== License Clarification
-
-In cases where the licensing is unclear,
-it may be necessary to contact the copyright holders
-to confirm the licensing of code or content.
-In those situations,
-it is _always_ preferred to ask upstream to resolve the licensing confusion
-by documenting the licensing and releasing an updated tarball.
-However, this is not always possible to achieve.
-
-== License: field
-
-Every Fedora package must contain a `+License:+` entry.
-Maintainers should be aware that the contents
-of the `+License:+` field are understood to not be legally binding
-(only the source code itself is),
-but maintainers must make every possible effort
-to be accurate when filling the `+License:+` field.
-
-The `License:` field refers
-to the licenses of the contents of the *_binary_* rpm.
-
-This policy and examples can be found at
-xref:legal::license-field.adoc[License: field in spec file].
-
-=== Valid License Short Names
-
-The `+License:+` field for new packages as of July 2022
-must be filled with the appropriate SPDX license identifier
-or expression from the list of
-xref:legal::allowed-licenses.adoc[allowed licenses] for Fedora.
-Note that some licenses may be allowed
-for only certain types of material,
-e.g., fonts, content, or documentation.
-
-The https://spdx.org/licenses/[SPDX License List]
-provides identifiers for each individual license
-or exception based on a set of matching guidelines.
-SPDX license expressions cover situations
-where multiple licenses apply to a package,
-where there is a choice of a license,
-and where licenses are coupled with exceptions or additional permissions.
-
-xref:legal::license-field.adoc[License: field in Spec file]
-contains examples and further explanations
-for using SPDX expressions in the `License:` field.
-
-For more information on what to do
-if you find a license that is not on the Fedora list,
-does not have a corresponding SPDX license identifier or expression,
-or other process questions,
-see xref:legal::license-review-process.adoc[License Review Process].
diff --git a/guidelines/modules/ROOT/pages/Lisp.adoc b/guidelines/modules/ROOT/pages/Lisp.adoc
deleted file mode 100644
index 8016db4..0000000
--- a/guidelines/modules/ROOT/pages/Lisp.adoc
+++ /dev/null
@@ -1,128 +0,0 @@
-= Lisp Packaging Guidelines
-
-This document seeks to document the conventions and customs surrounding the proper packaging of Common Lisp implementations and libraries in Fedora.
-This document does _not_ describe conventions and customs for application programs that are written in Common Lisp.
-
-== Introduction
-
-Most Common Lisp implementations provide a compiler to generate their own binary representation of source. These binary files typically end in .fasl (for Fast Load). These .fasl files are not compatible across Common Lisp implementations, or even between different versions of the same implementation. This unique property calls for special support on the packaging front.
-
-The Common Lisp community currently rallies around a common packaging and deployment technology called asdf (Another System Definition Format). Projects deployed using asdf include a system definition file. These files include information about project dependencies, licensing, and the authors. Projects don't typically distribute binaries, but rather depend on the asdf utilities to compile the Lisp source code on demand. When you run program that depends on a library managed by asdf, the asdf system will automatically compile the dependent Lisp code on demand and cache the results.
-
-The Debian Lisp community have developed tools and guidelines for packaging and maintaining asdf managed libraries on Linux systems. Their tool is called common-lisp-controller and, combined with asdf, it ensures that .fasl files are managed properly on the system. For instance, when a Common Lisp implementation is upgraded, the .fasl files for all of the packages built using the old implementation are deleted so that new ones may be generated on demand.
-
-The rest of this packaging guideline aims to describe how to package Common Lisp implementations, libraries and programs to take advantage of asdf and the common-lisp-controller.
-
-== Guidelines for Libraries and Programs written in Common Lisp
-
-=== Naming
-
-Lisp libraries should have their package names prefixed with "cl-", except in the case where the library name already starts with "cl-".
-
-Rationale: There is some overlap between Lisp library names and existing Fedora packages. Creating a special name space for Lisp libraries should simplify life for everybody.
-
-=== -devel sub-package
-
-Pure lisp libraries do not require -devel sub-packages, as they install source code by default.
-
-=== Use of asdf
-
-Libraries should be managed by asdf, a packaging format for Common Lisp libraries (see the cl-asdf package for details). Most modern Lisp libraries already ship with asdf system definition files (with names typically ending in ".asd"). If none exist, then one will have to be written. The contents of these files is not all that different from an RPM .spec file, so this should not be too difficult for a Lisp-savvy packager. The ASDF manual describing how to write .asd files is available https://common-lisp.net/project/asdf/asdf.html[here].
-
-=== Install location and hooking into the common-lisp-controller
-
-Libraries should depend on the common-lisp-controller package.
-Lisp source should be installed in %\{_datadir}/common-lisp/source/.
-The package should own that directory. The parent directories are owned by the common-lisp-controller package.
-A symlink to the asdf system definition file should be created from %\{_datadir}/common-lisp/systems/.asd to %\{_datadir}/common-lisp/source//.asd (this target directory is also owned by common-lisp-controller).
-The %post section should call `+register-common-lisp-source+`.
-The %preun section should call `+unregister-common-lisp-source+`.
-These scripts are provided by `+common-lisp-controller+`.
-
-=== Spec file template
-
-....
-Name:           # see normal package guidelines
-Version:        # see normal package guidelines
-Release:        1%{?dist}
-Summary:        # see normal package guidelines (SNPG)
-
-Group:          # SNPG
-License:        # SNPG
-URL:            # SNPG
-Source:         # SNPG
-BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
-BuildRequires:   common-lisp-controller
-Requires:        common-lisp-controller
-Requires(post):  common-lisp-controller
-Requires(preun): common-lisp-controller
-
-%description
-
-%prep
-%setup -q
-
-%build
-
-%install
-# Replace @NAME@ below with the Common Lisp library name, which may be different from the
-# package name if it is not already prefixed with "cl-".
-
-mkdir -m 755 -p %{buildroot}%{_datadir}/common-lisp/source/@NAME@
-mkdir -m 755 -p %{buildroot}%{_datadir}/common-lisp/systems
-for s in *.lisp; do
-  install -m 644 $s %{buildroot}%{_datadir}/common-lisp/source/@NAME@;
-done;
-for s in *.asd; do
-  install -m 644 $s %{buildroot}%{_datadir}/common-lisp/source/@NAME@;
-done;
-cd %{buildroot}%{_datadir}/common-lisp/source/@NAME@
-for asd in *.asd; do
-  ln -s %{_datadir}/common-lisp/source/@NAME@/$asd ../../systems;
-done
-
-%post
-register-common-lisp-source @NAME@
-
-%preun
-unregister-common-lisp-source @NAME@
-
-%files
-%doc
-%{_datadir}/common-lisp/source/@NAME@
-%{_datadir}/common-lisp/systems/@NAME@.asd
-
-%changelog
-....
-
-== Guidelines for Common Lisp implementations
-
-=== Naming
-
-There are no special requirements here. Common Lisp implementations should be packaged using their normal project name.
-
-=== -devel sub-package
-
-Common Lisp implementations do not require -devel sub-packages, and they necessarily include all development tools by default.
-
-=== Use of asdf
-
-Common Lisp implementations should be able to load asdf by simply entering "(require 'asdf)" at the Lisp Read-Eval-Print loop (REPL). This may involve modifying search paths or related changes at build time.
-
-=== Install location and hooking into the common-lisp-controller
-
-Common Lisp implementations should depend on the common-lisp-controller package.
-
-Common Lisp implementations should install a script in %\{_libdir}/common-lisp/bin/.sh that supports a single command on the command line: "install-clc". This should load %\{_datadir}/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp, call (common-lisp-controller:init-common-lisp-controller-v4 ) and then save the resulting image as default for the system.
-
-The %post section should call `+register-common-lisp-implementation+`.
-The %preun section should call `+unregister-common-lisp-implementation+`.
-
-These scripts, and the `+%{_libdir}/common-lisp/bin+` directory are provided and owned by the common-lisp-controller package.
-
-All implementations should be modified to load common-lisp-controller's `+%{_sysconfdir}/lisp-config.lisp+` on startup.
-
-== Further reading
-
-See https://www.cliki.net/common-lisp-controller and https://common-lisp.net/project/asdf/ for more details on common-lisp-controller and asdf.
diff --git a/guidelines/modules/ROOT/pages/Lua.adoc b/guidelines/modules/ROOT/pages/Lua.adoc
deleted file mode 100644
index 941362a..0000000
--- a/guidelines/modules/ROOT/pages/Lua.adoc
+++ /dev/null
@@ -1,114 +0,0 @@
-= Lua Packaging Guidelines
-:toc:
-
-== What is Lua?
-
-As described on the https://www.lua.org/[Lua website], Lua is
-
-"Lua is a powerful, efficient, lightweight, embeddable scripting language.
-It supports procedural programming, object-oriented programming, functional
-programming, data-driven programming, and data description."
-
-To learn Lua, read https://www.lua.org/pil/contents.html[Programming in Lua].
-
-== Spec Template for a Lua Package
-
-Many Lua packages use http://luarocks.org/[Lua-rocks] for packaging. It is helpful
-to examine the `+.rockspec+` specification as a guide in writing your spec file.
-Some packages require compilation of C programs, but others may be pure Lua. Both
-will have very similar install locations.
-
-....
-Summary:        Lua integration with libev
-Name:           lua-ev
-License:        MIT
-
-Version:        1.5
-Release:        2%{?dist}
-
-URL:            https://github.com/brimworks/lua-ev
-Source0:        %{url}/archive/v%{version}/%{name}-%{version}.tar.gz
-
-BuildRequires:  cmake
-BuildRequires:  gcc
-BuildRequires:  libev-devel
-BuildRequires:  lua-devel
-
-%description
-Event loop programming with Lua.
-
-%prep
-%autosetup -n %{name}-%{version} 
-
-%build
-%cmake -DINSTALL_CMOD=%{lua_libdir}
-%cmake_build
-
-%install
-%cmake_install 
-
-%check
-#packaged tests do not work directly
-#Use example program as a smoke test
-LUA_CPATH=%{buildroot}%{lua_libdir}/?.so \
-lua example.lua
-LUA_CPATH=%{buildroot}%{lua_libdir}/?.so \
-lua -e 'ev = require "ev"; print(ev.version())'
-
-%files
-%license README
-%doc example.lua
-%{lua_libdir}/ev.so
-
-%changelog
-* Thu Dec 08 2022 Benson Muite <benson_muite@emailplus.org> - 1.5-1
-- Use README as license
-
-* Sat Nov 19 2022 Benson Muite <benson_muite@emailplus.org> - 1.5-2
-- Fix install location based on review
-- Add further smoke test
-
-* Wed Nov 16 2022 Benson Muite <benson_muite@emailplus.org> - 1.5-1
-- Initial release
-....
-
-== Naming
-
-Lua add-on packages generally follow the naming scheme of `+lua-modulename+`
--- e.g. `+lua-filesystem+`, `+lua-lpeg+`, `+lua-moonscript+`. If the module name
-makes it clear that it is an add-on for Lua, though, the module name
-itself is sufficient. e.g. `+lutok+`.
-
-Use your judgement -- e.g. the second `+l+` in `+lua-lpeg+` already stands for Lua,
-but it might not be seen as unambiguous enough.
-
-== Macros
-
-The following macros for packaging lua extensions are provided by the
-`+lua-devel+` package:
-
-[%header,cols=2*]
-|===
-| Macro             | Description
-| `+%lua_version+`  | version of system installed lua
-| `+%lua_libdir+`   | installation directory for compiled modules
-| `+%lua_pkgdir+`   | installation directory for arch-independent modules
-| `+%lua_requires+` | declares the needed runtime dependencies for the binary package
-|===
-
-For EPEL, define the following macros at the top of your spec file:
-
-....
-%{!?lua_version: %global lua_version %{lua: print(string.sub(_VERSION, 5))}}
-# for compiled modules
-%{!?lua_libdir: %global lua_libdir %{_libdir}/lua/%{lua_version}}
-# for arch-independent modules
-%{!?lua_pkgdir: %global lua_pkgdir %{_datadir}/lua/%{lua_version}}
-....
-
-To make the package pull the correct runtime dependencies, declare them like this:
-
-....
-Requires: lua >= %{lua_version}
-Requires: lua <  %{lua: os.setlocale('C'); print(string.sub(_VERSION, 5) + 0.1)}
-....
diff --git a/guidelines/modules/ROOT/pages/MPI.adoc b/guidelines/modules/ROOT/pages/MPI.adoc
deleted file mode 100644
index 9a488fd..0000000
--- a/guidelines/modules/ROOT/pages/MPI.adoc
+++ /dev/null
@@ -1,210 +0,0 @@
-= Message Passing Interface
-
-== Introduction
-
-Message Passing Interface (MPI) is an API for parallelization of programs across multiple nodes and has been around since 1994 https://en.wikipedia.org/wiki/Message_Passing_Interface[1]. MPI can also be used for parallelization on SMP machines and is considered very efficient in it too (close to 100% scaling on parallelizable code as compared to ~80% commonly obtained with threads due to unoptimal memory allocation on NUMA machines). Before MPI, about every manufacturer of supercomputers had their own programming language for writing programs; MPI made porting software easy.
-
-There are many MPI implementations available, such as https://www.open-mpi.org/[Open MPI] (the default MPI compiler in Fedora and the MPI compiler used in RHEL), https://www.mpich.org/[MPICH] (in Fedora and RHEL) and
-https://mvapich.cse.ohio-state.edu/[MVAPICH1 and MVAPICH2] (in RHEL but not yet in Fedora).
-
-As some MPI libraries work better on some hardware than others, and some software works best with some MPI library, the selection of the library used must be done in user level, on a session specific basis. Also, people doing high performance computing may want to use more efficient compilers than the default one in Fedora (gcc), so one must be able to have many versions of the MPI compiler each compiled with a different compiler installed at the same time. This must be taken into account when writing spec files.
-
-== Packaging of MPI compilers
-
-The files of MPI compilers MUST be installed in the following directories:
-
-[cols=",",options="header",]
-|===================================================================
-|File type |Placement
-|Binaries |`+%{_libdir}/%{name}/bin+`
-|Libraries |`+%{_libdir}/%{name}/lib+`
-|[[PackagingDrafts/Fortran |Fortran modules]] |`+%{_fmoddir}/%{name}+`
-|[[Packaging/Python |Python modules]] |`+%{python2_sitearch}/%{name}+`
-`+%{python3_sitearch}/%{name}+`
-|Config files |`+%{_sysconfdir}/%{name}-%{_arch}+`
-|===================================================================
-
-As include files and manual pages are bound to overlap between different MPI implementations, they MUST also placed outside normal directories. It is possible that some man pages or include files (either those of the MPI compiler itself or of some MPI software installed in the compiler's directory) are architecture specific (e.g. a definition on a 32-bit arch differs from that on a 64-bit arch), the directories that MUST be used are as follows:
-
-[cols=",",options="header",]
-|================================================
-|File type |Placement
-|Man pages |`+%{_mandir}/%{name}-%{_arch}+`
-|Include files |`+%{_includedir}/%{name}-%{_arch}+`
-|================================================
-
-Architecture independent parts (except headers which go into `+-devel+`) MUST be placed in a `+-common+` subpackage that is `+BuildArch: noarch+`.
-
-The runtime of MPI compilers (mpirun, the libraries, the manuals etc) MUST be packaged into %\{name}, and the development headers and libraries into %\{name}-devel.
-
-As the compiler is installed outside `+PATH+`, one needs to load the relevant variables before being able to use the compiler or run MPI programs. This is done using xref:EnvironmentModules.adoc[environment modules].
-
-The module file MUST be installed under `+%{_sysconfdir}/modulefiles/mpi+`. This allows as user with only one mpi implementation installed to load the module with:
-
-....
-module load mpi
-....
-
-The module file MUST have the line:
-
-....
-conflict mpi
-....
-
-to prevent concurrent loading of multiple mpi modules.
-
-The module file MUST prepend `+$MPI_BIN+` into the user's `+PATH+` and prepend `+$MPI_LIB+` to `+LD_LIBRARY_PATH+`.
-The module file MUST also set some helper variables (primarily for use in spec files):
-
-[cols=",,",options="header",]
-|==========================================================================================
-|Variable |Value |Explanation
-|`+MPI_BIN+` |`+%{_libdir}/%{name}/bin+` |Binaries compiled against the MPI stack
-|`+MPI_SYSCONFIG+` |`+%{_sysconfdir}/%{name}-%{_arch}+` |MPI stack specific configuration files
-|`+MPI_FORTRAN_MOD_DIR+` |`+%{_fmoddir}/%{name}+` |MPI stack specific Fortran module directory
-|`+MPI_INCLUDE+` |`+%{_includedir}/%{name}-%{_arch}+` |MPI stack specific headers
-|`+MPI_LIB+` |`+%{_libdir}/%{name}/lib+` |Libraries compiled against the MPI stack
-|`+MPI_MAN+` |`+%{_mandir}/%{name}-%{_arch}+` |MPI stack specific man pages
-|`+MPI_PYTHON2_SITEARCH+` |`+%{python2_sitearch}/%{name}+` |MPI stack specific Python 2 modules
-|`+MPI_PYTHON3_SITEARCH+` |`+%{python3_sitearch}/%{name}+` |MPI stack specific Python 3 modules
-|`+MPI_COMPILER+` |`+%{name}-%{_arch}+` |Name of compiler package, for use in e.g. spec files
-|`+MPI_SUFFIX+` |`+_%{name}+` |The suffix used for programs compiled against the MPI stack
-|==========================================================================================
-
-As these directories may be used by software using the MPI stack, the MPI runtime package MUST own all of them.
-
-MUST: By default, NO files are placed in `+/etc/ld.so.conf.d+`. If the packager wishes to provide alternatives support, it MUST be placed in a subpackage along with the ld.so.conf.d file so that alternatives support does not need to be installed if not wished for.
-
-MUST: If the maintainer wishes for the environment module to load automatically by use of a scriptlet in /etc/profile.d or by some other mechanism, this MUST be done in a subpackage.
-
-MUST: The MPI compiler package MUST provide an RPM macro that makes loading and unloading the support easy in spec files, e.g. by placing the following in `+/etc/rpm/macros.openmpi+`
-
-....
-%_openmpi_load \
- . /etc/profile.d/modules.sh; \
- module load mpi/openmpi-%{_arch}; \
- export CFLAGS="$CFLAGS %{optflags}";
-%_openmpi_unload \
- . /etc/profile.d/modules.sh; \
- module unload mpi/openmpi-%{_arch};
-....
-
-loading and unloading the compiler in spec files is as easy as `+%{_openmpi_load}+` and `+%{_openmpi_unload}+`.
-
-Automatic setting of the module loading path in python interpreters is done using a `+.pth+` file placed in one of the directories normally searched for modules (`+%{python2_sitearch}+`, `+%{python3_sitearch}+`). Those `+.pth+` files should append the directory specified with $MPI_PYTHON2_SITEARCH or $MPI_PYTHON3_SITEARCH environment variable, depending on the interpreter version, to `+sys.path+`, and do nothing if those variables are unset. Module files MUST NOT set PYTHONPATH directly, since it cannot be set for both Python versions at the same time.
-
-If the environment module sets compiler flags such as `+CFLAGS+` (thus overriding the ones exported in `+%configure+`, the RPM macro MUST make them use the Fedora optimization flags `+%{optflags}+` once again (as in the example above in which the openmpi-%\{_arch} module sets CFLAGS).
-
-== Packaging of MPI software
-
-Software that supports MPI MUST be packaged also in serial mode [i.e. no MPI], if it is supported by upstream. (for instance: `+foo+`).
-
-If possible, the packager MUST package versions for each MPI compiler in Fedora (e.g. if something can only be built with mpich and mvapich2, then mvapich1 and openmpi packages do not need to be made).
-
-MPI implementation specific files MUST be installed in the directories used by the used MPI compiler (`+$MPI_BIN+`, `+$MPI_LIB+` and so on).
-
-The binaries MUST be suffixed with `+$MPI_SUFFIX+` (e.g. _openmpi for Open MPI, _mpich for MPICH and _mvapich2 for MVAPICH2). This is for two reasons: the serial version of the program can still be run when an MPI module is loaded and the user is always aware of the version s/he is running. This does not need to hurt the use of shell scripts:
-
-....
-# Which MPI implementation do we use?
-
-#module load mpi/mvapich2-i386
-#module load mpi/openmpi-i386
-module load mpi/mpich-i386
-
-# Run preprocessor
-foo -preprocess < foo.in
-# Run calculation
-mpirun -np 4 foo${MPI_SUFFIX}
-# Run some processing
-mpirun -np 4 bar${MPI_SUFFIX} -process
-# Collect results
-bar -collect
-....
-
-The MPI enabled bits MUST be placed in a subpackage with the suffix denoting the MPI compiler used (for instance: `+foo-openmpi+` for Open MPI [the traditional MPI compiler in Fedora] or `+foo-mpich+` for MPICH). For directory ownership and to guarantee the pickup of the correct MPI runtime, the MPI subpackages MUST require the correct MPI compiler's runtime package.
-
-Each MPI build of shared libraries SHOULD have a separate -libs subpackage for the libraries (e.g. foo-mpich-libs). As in the case of MPI compilers, library configuration (in `+/etc/ld.so.conf.d+`) MUST NOT be made.
-
-In case the headers are the same regardless of the compilation method and architecture (e.g. 32-bit serial, 64-bit Open MPI, MPICH), they MUST be split into a separate `+-headers+` subpackage (e.g. 'foo-headers'). Fortran modules are architecture specific and as such are placed in the (MPI implementation specific) `+-devel+` package (foo-devel for the serial version and foo-openmpi-devel for the Open MPI version).
-
-Each MPI build MUST have a separate -devel subpackage (e.g. foo-mpich-devel) that includes the development libraries and `+Requires: %{name}-headers+` if such a package exists. The goal is to be able to install and develop using e.g. 'foo-mpich-devel' without needing to install e.g. openmpi or the serial version of the package.
-
-Files must be shared between packages as much as possible. Compiler independent parts, such as data files in `+%{_datadir}/%{name}+` and man files MUST be put into a `+-common+` subpackage that is required by all of the binary packages (the serial package and all of the MPI packages).
-
-=== A sample spec file
-
-....
-# Define a macro for calling ../configure instead of ./configure
-%global dconfigure %(printf %%s '%configure' | sed 's!\./configure!../configure!g')
-
-Name: foo
-Requires: %{name}-common = %{version}-%{release}
-
-%package common
-
-%package openmpi
-BuildRequires: openmpi-devel
-# Require explicitly for dir ownership and to guarantee the pickup of the right runtime
-Requires: openmpi
-Requires: %{name}-common = %{version}-%{release}
-
-%package mpich
-BuildRequires: mpich-devel
-# Require explicitly for dir ownership and to guarantee the pickup of the right runtime
-Requires: mpich
-Requires: %{name}-common = %{version}-%{release}
-
-%build
-# Have to do off-root builds to be able to build many versions at once
-
-# To avoid replicated code define a build macro
-%define dobuild() \
-mkdir $MPI_COMPILER; \
-cd $MPI_COMPILER; \
-%dconfigure --program-suffix=$MPI_SUFFIX ;\
-make %{?_smp_mflags} ; \
-cd ..
-
-# Build serial version, dummy arguments
-MPI_COMPILER=serial MPI_SUFFIX= %dobuild
-
-# Build parallel versions: set compiler variables to MPI wrappers
-export CC=mpicc
-export CXX=mpicxx
-export FC=mpif90
-export F77=mpif77
-
-# Build OpenMPI version
-%{_openmpi_load}
-%dobuild
-%{_openmpi_unload}
-
-# Build mpich version
-%{_mpich_load}
-%dobuild
-%{_mpich_unload}
-
-%install
-# Install serial version
-make -C serial install DESTDIR=%{buildroot} INSTALL="install -p" CPPROG="cp -p"
-
-# Install OpenMPI version
-%{_openmpi_load}
-make -C $MPI_COMPILER install DESTDIR=%{buildroot} INSTALL="install -p" CPPROG="cp -p"
-%{_openmpi_unload}
-
-# Install MPICH version
-%{_mpich_load}
-make -C $MPI_COMPILER install DESTDIR=%{buildroot} INSTALL="install -p" CPPROG="cp -p"
-%{_mpich_unload}
-
-
-%files # All the serial (normal) binaries
-
-%files common # All files shared between the serial and different MPI versions
-
-%files openmpi # All openmpi linked files
-
-%files mpich # All mpich linked files
-....
diff --git a/guidelines/modules/ROOT/pages/Meson.adoc b/guidelines/modules/ROOT/pages/Meson.adoc
deleted file mode 100644
index 8f2f2cd..0000000
--- a/guidelines/modules/ROOT/pages/Meson.adoc
+++ /dev/null
@@ -1,81 +0,0 @@
-= Meson Packaging Guidelines
-
-This document provides best practices for the usage of https://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.
-
-== Build Dependencies
-
-You *MUST* add following BuildRequires:
-
-....
-BuildRequires: meson
-....
-
-== Available Macros
-
-You will generally make use of these in your specs:
-
-`+%meson+`::
-  Defines CFLAGS, LDFLAGS, etc. and calls `+%__meson+` with appropriate parameters (`+--libdir=%{_libdir}+` and such).
-  You can pass `+-Doption=value+` to this macro in order to set options for the buildsystem.
-`+%meson_build+`::
-  An alias for `+%ninja_build -C %{_vpath_builddir}+`.
-`+%meson_install+`::
-  An alias for `+%ninja_install -C %{_vpath_builddir}+`.
-`+%meson_test+`::
-  An alias for `+%ninja_test -C %{_vpath_builddir}+`.
-
-It is rarely necessary (but permissible) to use or alter these:
-
-`+%__meson+`::
-  The path to the meson executable
-
-Also see xref:vpath.adoc[Defining source and build directories].
-
-== Example RPM spec file
-
-....
-%global _vpath_srcdir sdk/%{name}/projects/meson
-
-Name:           angelscript
-Version:        2.31.1
-Release:        1%{?dist}
-Summary:        Flexible cross-platform scripting library
-
-License:        zlib
-URL:            https://www.angelcode.com/angelscript/
-Source:         %{url}sdk/files/%{name}_%{version}.zip
-
-BuildRequires:  meson
-BuildRequires:  gcc
-
-%package devel
-Summary:        Development libraries and header files for %{name}
-Requires:       %{name}%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}
-
-%description devel
-%{summary}.
-
-%prep
-%autosetup -c
-
-%conf
-%meson
-
-%build
-%meson_build
-
-%install
-%meson_install
-
-%check
-%meson_test
-
-%files
-%{_libdir}/lib%{name}.so.*
-
-%files devel
-%{_libdir}/lib%{name}.so
-%{_includedir}/%{name}.h
-....
-
-*NOTE:* If building for < EPEL 10 then `%meson` should be in `%build`.
diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc
deleted file mode 100644
index 6c09a84..0000000
--- a/guidelines/modules/ROOT/pages/MinGW.adoc
+++ /dev/null
@@ -1,1116 +0,0 @@
-= Packaging Guidelines for MinGW Cross Compilers
-
-== Introduction
-
-The Fedora MinGW project's mission is to provide an excellent development
-environment for Fedora users who wish to cross-compile their programs to run on
-Windows, minimizing the need to use Windows at all. In the past developers have
-had to port and compile all of the libraries and tools they have needed, and
-this huge effort has happened independently many times over. We aim to eliminate
-duplication of work for application developers by providing a range of libraries
-and development tools which have already been ported to the MinGW cross-compiler
-environment. This means that developers will not need to recompile the
-application stack themselves, but can concentrate just on the changes needed to
-their own application.
-
-The targets Win32 and Win64 are supported with the MSVCRT runtime. The target
-Win64 with the UCRT runtime is also supported, however, only for the base
-toolchain. Builds for UCRT are not enabled for packages above the toolchain
-at this time.
-
-== Separate vs integrated MinGW source packages
-
-There are two permitted ways to provide MinGW builds of software in Fedora:
-
-* **Separate source packages**: There are distinct RPM spec files for the
-  native and MinGW builds, maintained as independent components of Fedora.
-  This is the traditional approach to MinGW packaging in Fedora
-
-* **Integrated source packages**: There is a single RPM spec file for the
-  native and MinGW builds, as a single component of Fedora. The MinGW builds
-  are emitted as binary sub-RPMs. This is the modern, preferred, approach to
-  MinGW packaging in Fedora.
-
-The traditional approach of completely separated source packages was adopted
-initially because of concerns that instability in the MinGW toolchain or
-Windows builds may prevent timely updates to the native package. Experience
-in Fedora since then has shown that is not generally a problem that impacts
-most packages, especially where Windows support is an explicitly tested
-deliverable of the upstream project.
-
-Using the separate packaging approach has a significantly higher overhead:
-
-* The addition of MinGW support must go through the full Fedora review
-  process for new packages, largely duplicating review already performed
-  on the native package.
-
-* There is an ongoing burden for the maintainer to ensure the MinGW source
-  package tracks changes to the corresponding native source package as it
-  rebases to new releases.
-
-* There is additional work in handling patches/updates in response to bug
-  reports. Bug reports are often only reported against one of the two
-  components not both, but with security vulnerabilities there are twice
-  the number of bug reports created. There are then also multiple koji
-  builds and updates to handle.
-
-With the integrated packaging approach there is a small extra overhead on the
-native package maintainer to ensure MinGW builds keep working and a small
-additional load of MinGW specific bug reports. This is usually negligible
-compared to the overhead of maintaining separated packages.
-
-With this in mind, the recommendation of the MinGW SIG is thus:
-
-* Where the same Fedora contributor intends to maintain both the native
-  and MinGW builds of a package, they **MUST** use the integrated packaging
-  approach.
-
-* Where the upstream project explicitly supports the Windows platform as
-  a build target and has automated CI, contributors **SHOULD** prefer the
-  integrated MinGW packaging approach. Native package maintainers **SHOULD**
-  ordinarily accept addition of integrated MinGW support. If declining the
-  request the native maintainer should give a rationale for their decision.
-
-* Where the upstream project does not have automated testing of Windows
-  builds, the MinGW package support **MAY** use either packaging approach.
-  The native maintainer may decline the request for integrated packaging
-  at their discretion.
-
-* Where the upstream project only supports Windows builds, the separate
-  packaging approach **MUST** be used. There will be no corresponding
-  native package in Fedora expected. This situation is very rare.
-
-* When a contributor proposes a new native package to Fedora that provides
-  libraries that are known to support Windows, the reviewer **SHOULD**
-  inquire whether the contributor would like to add MinGW builds at the
-  same time. The contributor may decline this request at their discretion.
-
-== Adding MinGW support alongside a new native package
-
-When a corresponding native package does not already exist, it will always
-be required to go through the standard Fedora new package review process.
-The proposed MinGW support **MUST** follow the integrated packaging approach
-to provide both the MinGW and native builds, where technically possible.
-As noted in the previous section, in some rare situations there will be no
-corresponding native package, thus requiring the separate pacakaging approach
-to be taken.
-
-== Adding MinGW support to an existing native package
-
-When a corresponding native package is already present in Fedora, the
-preference is to add MinGW support to the native source package.
-
-Where the source package changes are simple, the contributor **SHOULD**:
-
- * Make the required spec file additions in their fork of the package
- * Submit a koji scratch-build to prove the changes have the expected
-   effect
- * Open a merge request against the native package with the spec changes,
-   adding a link to the koji scratch-build results as a comment.
-
-The existing native package maintainer thus gets clear view of the impact of
-the MinGW additions to their package, to evaluate the viability of following
-the integrated packaging approach.
-
-Where there is doubt about the viability of following the integrated package
-approach, a bug **MAY** be opened against the package ahead of starting work
-to discuss the two packaging options with the native package maintainer.
-
-If the native maintainer declines the proposal to add MinGW support to the
-existing package, the regular Fedora new package process MUST be followed
-to introduce MinGW support following the separate packaging approach.
-
-== Track Fedora native package versions
-
-In general terms, cross-compiled MinGW versions of packages which are already
-natively available in Fedora, should follow the native Fedora package as closely
-as possible. This means they should stay at the same version, include all the
-same patches as the native Fedora package, and be built with the same
-configuration options.
-
-The preferred way to achieve this goal is for the MinGW support to use the
-integrated packaging approach.
-
-== Follow Fedora policy
-
-Cross compiled MinGW packages must follow Fedora policy, except where noted in
-this document. Cross compiled packages go through the same review process, GIT
-admin process etc. as other Fedora packages.
-
-== Package naming
-
-MinGW packages require special naming to denote the appropriate CPU architecture
-the binaries have been built for. There should *never* be a package prefixed
-with `+mingw-+` output during a build. The `+mingw-+` prefix is exclusive for
-RPM spec file names and the source RPM file name. The CPU architecture specific
-packages are created by sections with `+%files -n mingw32-foo+`,
-`+%files -n mingw64-foo+` or `+%files -n ucrt64-foo+`.
-
-[cols=",",]
-|=======================================================
-|`+mingw-+` |Used for source package and RPM spec name (only where the separate packaging approach is chosen)
-|`+mingw32-+` |Used for packages which are built for Win32 with the MSVCRT runtime
-|`+mingw64-+` |Used for packages which are built for Win64 with the MSVCRT runtime
-|`+ucrt64-+` |Used for packages which are built for Win64 with the UCRT runtime
-|=======================================================
-
-== Base packages
-
-The base packages provide a root filesystem, base libraries, binutils (basic
-programs like 'strip', 'ld' etc), the compiler (gcc) and the Win32/Win64 API.
-Packages may need to depend on one or more of these. In particular, almost all
-packages should BuildRequire `+mingw32-filesystem+`, `+mingw64-filesystem+`,
-`+mingw32-gcc+` and `+mingw64-gcc+`.
-
-[cols=",",]
-|=================================================================================================================================================================================================================================
-|`+mingw32-filesystem+` / `+mingw64-filesystem+` / `+ucrt64-filesystem+` |Core filesystem directory layout, and RPM macros for spec files. Equivalent to 'filesystem' RPM
-|`+mingw32-binutils+` / `+mingw64-binutils+` / `+ucrt64-binutils+` |Cross-compiled binutils (utilities like 'strip', 'as', 'ld') which understand Windows executables and DLLs. Equivalent to 'binutils' RPM
-|`+mingw32-gcc+` / `+mingw64-gcc+` / `+ucrt64-gcc+` |GNU compiler collection. Compilers for C and C++ which cross-compile to a Windows target. Equivalent to gcc RPM
-|`+mingw32-crt+` / `+mingw64-crt+` / `+ucrt64-crt+` |Base libraries for core MinGW runtime & development environment. Equivalent to 'glibc' RPM
-|`+mingw32-headers+` / `+mingw64-headers+` / `+ucrt64-headers+` |Win32 and Win64 API. A free (public domain) reimplementation of the header files required to link to the Win32 and Win64 API. No direct equivalent in base Fedora - glibc-devel is closest
-|=================================================================================================================================================================================================================================
-
-== Build for multiple targets
-
-The goal of the MinGW framework is to provide an easy way for package
-maintainers to build their packages for multiple targets using one .spec file.
-To aid developers in this several RPM macros have been developed which are part
-of the mingw-filesystem package. These RPM macros will be explained later on in
-these guidelines.
-
-By default MinGW support will be built for both the Win32 and Win64 targets
-with the MSVCRT runtime. Building of the Win64 target with the UCRT64 runtime
-is not yet enabled by default.
-
-When a package can only be built for a subset of these targets this can be
-indicated by setting one or more of these:
-
-[cols=",",]
-|===============================================================
-|`+%global mingw_build_win32 0+` |Don't build for the Win32 target with the MSVCRT runtime
-|`+%global mingw_build_win64 0+` |Don't build for the Win64 target with the MSVCRT runtime
-|`+%global mingw_build_ucrt64 0+` |Don't build for the Win64 target with the UCRT runtime
-|===============================================================
-
-== One source RPM, separate binary RPMs per-target
-
-Each cross compiled MinGW package which builds binaries for a specific target
-should put the binaries for that target in a separate subpackage. So if a
-package `+mingw-foo+` or `+foo+` builds binaries for the Win32 and Win64 targets
-with the MSVCRT runtime, then the source RPM should provide two subpackages
-named `+mingw32-foo+` and `+mingw64-foo+`. If a package builds for the UCRT
-runtime, it will also have a `+ucrt64-foo+` subpackage.
-
-This means that a spec file must contains %package and %files sections for all
-the targets.
-
-When using the separate packaging approach, packages containing translations
-must use `+%mingw_find_lang+` instead of `+%find_lang+`.
-
-When using the integrated packaging approach, packages containing translations
-must use `+%find_lang` followed by `+%mingw_find_lang+`.
-
-This causes all translation filelists to be split in per-target filelists. For
-example: when a spec file contains something like this:
-
-[source, rpm-spec]
-----
- %install
- <snip>
- %mingw_find_lang foo
-----
-
-then one file per mingw target will get created named `+mingw32-foo.lang+`,
-`+mingw64-foo.lang+`, and `+ucrt64-foo.lang+`. These file lists can be
-included in the %files section for the targets:
-
-[source, rpm-spec]
-----
- %files -n mingw32-foo -f mingw32-foo.lang
- <snip>
- %files -n mingw64-foo -f mingw64-foo.lang
- <snip>
- %files -n ucrt64-foo -f ucrt64-foo.lang
-----
-
-== Filesystem layout
-
-Integration into the main root filesystem layout is as follows:
-
-....
-[root]
-  |
-  +- etc
-  |   |
-  |   +- rpm
-  |       |
-  |       +- macros.mingw
-  |       +- macros.mingw32
-  |       +- macros.mingw64
-  |
-  +- usr
-      |
-      +- bin   - Links to MinGW cross compiler toolchain
-      |   |
-      |   +- i686-w64-mingw32-cpp
-      |   +- i686-w64-mingw32-gcc
-      |   +- i686-w64-mingw32-g++
-      |   +- x86_64-w64-mingw32-cpp
-      |   +- x86_64-w64-mingw32-gcc
-      |   +- x86_64-w64-mingw32-g++
-      |   +- x86_64-w64-mingw32ucrt-cpp
-      |   +- x86_64-w64-mingw32ucrt-gcc
-      |   +- x86_64-w64-mingw32ucrt-g++
-      |   +- ... etc..
-      |
-      +- lib
-      |   |
-      |   +- rpm
-      |       |
-      |       +- mingw-find-debuginfo.sh - extract debug information from Win32 and Win64 binaries
-      |       +- mingw-find-lang.sh - generates per-target file lists containing translations
-      |       +- mingw-find-provides.sh - extra DLL names
-      |       +- mingw-find-requires.sh - discover required DLL names
-      |
-      +- i686-w64-mingw32  - root of mingw toolchain and binaries for the Win32 target with MSVCRT runtime - see next diagram
-      +- x86_64-w64-mingw32  - root of mingw toolchain and binaries for the Win64 target with MSVCRT runtime - see next diagram+`
-      +- x86_64-w64-mingw32urt  - root of mingw toolchain and binaries for the Win64 target with UCRT runtime - see next diagram+`
-....
-
-The bulk of the packaged content is located under the respective MinGW root,
-one of `+/usr/i686-w64-mingw32+`, `+/usr/x86_64-w64-mingw32+` and
-`+/usr/x86_64-w64-mingw32ucrt+`:
-
-....
-[mingw-root]
-  |
-  +- bin  - Binutils toolchain binaries for the target
-  |   |
-  |   +- ar
-  |   +- as
-  |   +- dlltool
-  |   +- ld
-  |   +- ... etc ...
-  |
-  +- lib  - Binutils toolchain support libraries / files for the target
-  |
-  +- sys-root  - root for cross compiled MinGW binaries
-      |
-      +- mingw
-          |
-          +- bin     - cross-compiled MinGW binaries & runtime DLL parts
-          +- etc     - configuration files
-          +- include - include files for cross compiled MinGW libs
-          +- lib     - cross-compiled static MinGW libraries & linktime DLL parts
-          |   |
-          |   +- pkgconfig  - pkg-config definitions for libraries
-          |
-          +- share
-              |
-              +- man
-....
-
-== Filenames of the cross-compilers and binutils
-
-The MinGW cross-compilers and binutils are Fedora binaries and are therefore
-placed in `+%{_bindir}+` (i.e., `+/usr/bin+`) according to the FHS and Fedora
-guidelines.
-
-The MinGW cross-compilers and binutils which generate i686 binaries for Windows
-with the MSVCRT runtime are named:
-
-[source, rpm-spec]
-----
- %{_bindir}/i686-w64-mingw32-gcc
- %{_bindir}/i686-w64-mingw32-g++
- %{_bindir}/i686-w64-mingw32-ld
- %{_bindir}/i686-w64-mingw32-as
- %{_bindir}/i686-w64-mingw32-strip
- etc.
-----
-
-The same binaries are present in
-`+%{_prefix}/i686-w64-mingw32/bin+` without any prefix in the
-name, i.e.,
-
-[source, rpm-spec]
-----
- %{_prefix}/i686-w64-mingw32/bin/gcc
- %{_prefix}/i686-w64-mingw32/bin/g++
- %{_prefix}/i686-w64-mingw32/bin/ld
- %{_prefix}/i686-w64-mingw32/bin/as
- %{_prefix}/i686-w64-mingw32/bin/strip
- etc.
-----
-
-The same also applies for the x86_64 target with both MSVCRT
-and UCRT runtimes. The target with MSVCRT uses 'x86_64-w64-mingw32'
-as prefix instead of 'i686-w64-mingw32', while UCRT uses
-'x86_64-w64-mingw32ucrt'.
-
-== Naming of the root filesystem
-
-The root filesystem contains Windows executables and DLLs and any other
-Windows-only files. It is necessary both because we need to store Windows
-libraries in order to link further libraries which depend on them, and also
-because MinGW requires a root filesystem location.
-
-The location for Win32 target with MSVCRT runtime is provided by the macro:
-
-[source, rpm-spec]
-----
- %{mingw32_sysroot}   %{_prefix}/i686-w64-mingw32/sys-root
-----
-
-The Win64 target with MSVCRT runtime is provided by the macro:
-
-[source, rpm-spec]
-----
- %{mingw64_sysroot}   %{_prefix}/x86_64-w64-mingw32/sys-root
-----
-
-The Win64 target with UCRT runtime is provided by the macro:
-
-[source, rpm-spec]
-----
- %{ucrt64_sysroot}   %{_prefix}/x86_64-w64-mingw32ucrt/sys-root
-----
-
-
-
-== Standard mingw RPM macros
-
-The `+mingw-filesystem+` package provides a number of convenience macros for
-the cross compiled sysroot directories, and toolchain. It is mandatory to use
-these macros in all MinGW cross compiled packages submitted to Fedora.
-
-=== Toolchain macros
-
-The following macros are for the %build and %install section of the spec
-
-Generic macros:
-
-[cols=",,",]
-|==================================================================================================================================================
-|Macro |Available in mingw-filesystem |Explanation
-|mingw_cmake |>= 95 |Call the 'cmake' binary for all the configured targets
-|mingw_cmake_kde4 |>= 95 |Call the 'cmake' binary for all the configured targets with KDE4 specific parameters set
-|mingw_configure |>= 95 |Call the configure command for all the configured targets
-|mingw_make |>= 95 |Call the 'make' command for all the configured targets
-|mingw_make_build |>= 113|Call 'make -O -j<nprocs> V=1 VERBOSE=1' command for all configured targets
-|mingw_make_install |>= 113 |Call 'make install DESTDIR=$RPM_BUILD_ROOT 'INSTALL=/usr/bin/install -p' for all configured targets
-|mingw_meson |>= 104 |Call the meson binary for all the configured targets
-|mingw_ninja |>= 104 |Call the ninja binary for all the configured targets
-|mingw_objcopy |>= 95 |cross compiler 'objcopy' binary (which supports both Win32 and Win64 binaries)
-|mingw_objdump |>= 95 |cross compiler 'objdump' binary (which supports both Win32 and Win64 binaries)
-|mingw_qmake_qt4 |>= 95 |Call the Qt4 qmake binary for all configured targets (requires mingw32-qt-qmake and/or mingw64-qt-qmake to be installed)
-|mingw_qmake_qt5 |>= 96 |Call the Qt5 qmake binary for all configured targets (requires mingw32-qt5-qmake and/or mingw64-qt5-qmake to be installed)
-|mingw_strip |>= 95 |cross compiler 'strip' binary (which supports both Win32 and Win64 binaries)
-|==================================================================================================================================================
-
-Win32 with MSVCRT runtime specific macros:
-
-[cols=",,,",]
-|===================================================================================================================================================
-|Macro |Available in mingw32-filesystem | Value |Explanation
-|mingw32_ar |>= 95 |i686-w64-mingw32-ar |cross compiler 'ar' binary
-|mingw32_cc |>= 95 |i686-w64-mingw32-gcc |cross compiler 'gcc' binary
-|mingw32_cflags |>= 95 |-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 |Default compiler flags for C/C++ binaries
-|mingw32_cmake |>= 95 | |Call the 'cmake' binary for the Win32 target
-|mingw32_configure |>= 95 | |standard invocation for autotools 'configure' scripts
-|mingw32_cpp |>= 95 |i686-w64-mingw32-gcc -E |cross compiler 'cpp' binary
-|mingw32_env |>= 95 | |Set the correct environment variables for the Win32 target
-|mingw32_host |>= 95 |i686-w64-mingw32 |Host platform for build
-|mingw32_meson |>= 104 | |Call the meson binary for the Win32 target
-|mingw32_ninja |>= 104 | |Call the ninja binary for the Win32 target
-|mingw32_objcopy |>= 95 |i686-w64-mingw32-objcopy |cross compiler 'objcopy' binary
-|mingw32_objdump |>= 95 |i686-w64-mingw32-objdump |cross compiler 'objdump' binary
-|mingw32_pkg_config |>= 95 |i686-w64-mingw32-pkg-config |Call the pkg-config command for the Win32 target
-|mingw32_qmake_qt4 |>= 95 |mingw32-qmake-qt4 |Call the Qt4 qmake command for the Win32 target
-|mingw32_qmake_qt5 |>= 96 |mingw32-qmake-qt5 |Call the Qt5 qmake command for the Win32 target
-|mingw32_ranlib |>= 95 |i686-w64-mingw32-ranlib |cross compiler 'ranlib' binary
-|mingw32_strip |>= 95 |i686-w64-mingw32-strip |cross compiler 'strip' binary
-|mingw32_target |>= 95 |i686-w64-mingw32 |Target platform for build
-|===================================================================================================================================================
-
-Win64 with MSVCRT runtime specific macros:
-
-[cols=",,,",]
-|===================================================================================================================================================
-|Macro |Available in mingw64-filesystem | Value |Explanation
-|mingw64_ar |>= 95 |x86_64-w64-mingw32-ar |cross compiler 'ar' binary
-|mingw64_cc |>= 95 |x86_64-w64-mingw32-gcc |cross compiler 'gcc' binary
-|mingw64_cflags |>= 95 |-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 |Default compiler flags for C/C++ binaries
-|mingw64_cmake |>= 95 | |Call the 'cmake' binary for the Win64 target
-|mingw64_configure |>= 95 | |standard invocation for autotools 'configure' scripts
-|mingw64_cpp |>= 95 |x86_64-w64-mingw32-gcc -E |cross compiler 'cpp' binary
-|mingw64_env |>= 95 | |Set the correct environment variables for the Win64 target
-|mingw64_host |>= 95 |x86_64-w64-mingw32 |Host platform for build
-|mingw64_meson |>= 104 | |Call the meson binary for the Win64 target
-|mingw64_ninja |>= 104 | |Call the ninja binary for the Win64 target
-|mingw64_objcopy |>= 95 |x86_64-w64-mingw32-objcopy |cross compiler 'objcopy' binary
-|mingw64_objdump |>= 95 |x86_64-w64-mingw32-objdump |cross compiler 'objdump' binary
-|mingw64_pkg_config |>= 95 |x86_64-w64-mingw32-pkg-config |Call the pkg-config command for the Win64 target
-|mingw64_qmake_qt4 |>= 95 |mingw64-qmake-qt4 |Call the Qt4 qmake command for the Win64 target
-|mingw64_qmake_qt5 |>= 96 |mingw64-qmake-qt5 |Call the Qt5 qmake command for the Win64 target
-|mingw64_ranlib |>= 95 |x86_64-w64-mingw32-ranlib |cross compiler 'ranlib' binary
-|mingw64_strip |>= 95 |x86_64-w64-mingw32-strip |cross compiler 'strip' binary
-|mingw64_target |>= 95 |x86_64-w64-mingw32 |Target platform for build
-|===================================================================================================================================================
-
-Win64 with UCRT runtime specific macros:
-
-[cols=",,,",]
-|===================================================================================================================================================
-|Macro |Available in ucrt64-filesystem | Value |Explanation
-|ucrt64_ar |>= 133 |x86_64-w64-mingw32ucrt-ar |cross compiler 'ar' binary
-|ucrt64_cc |>= 133 |x86_64-w64-mingw32ucrt-gcc |cross compiler 'gcc' binary
-|ucrt64_cflags |>= 133 |-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 |Default compiler flags for C/C++ binaries
-|ucrt64_cmake |>= 133 | |Call the 'cmake' binary for the Win64 target
-|ucrt64_configure |>= 133 | |standard invocation for autotools 'configure' scripts
-|ucrt64_cpp |>= 133 |x86_64-w64-mingw32ucrt-gcc -E |cross compiler 'cpp' binary
-|ucrt64_env |>= 133 | |Set the correct environment variables for the Win64 target
-|ucrt64_host |>= 133 |x86_64-w64-mingw32 |Host platform for build
-|ucrt64_meson |>= 104 | |Call the meson binary for the Win64 target
-|ucrt64_ninja |>= 104 | |Call the ninja binary for the Win64 target
-|ucrt64_objcopy |>= 133 |x86_64-w64-mingw32ucrt-objcopy |cross compiler 'objcopy' binary
-|ucrt64_objdump |>= 133 |x86_64-w64-mingw32ucrt-objdump |cross compiler 'objdump' binary
-|ucrt64_pkg_config |>= 133 |x86_64-w64-mingw32ucrt-pkg-config |Call the pkg-config command for the Win64 target
-|ucrt64_qmake_qt4 |>= 133 |ucrt64-qmake-qt4 |Call the Qt4 qmake command for the Win64 target
-|ucrt64_qmake_qt5 |>= 133 |ucrt64-qmake-qt5 |Call the Qt5 qmake command for the Win64 target
-|ucrt64_ranlib |>= 133 |x86_64-w64-mingw32ucrt-ranlib |cross compiler 'ranlib' binary
-|ucrt64_strip |>= 133 |x86_64-w64-mingw32ucrt-strip |cross compiler 'strip' binary
-|ucrt64_target |>= 133 |x86_64-w64-mingw32 |Target platform for build
-|===================================================================================================================================================
-
-=== Filesystem location macros
-
-The following macros are for use in %build, %install and %files sections of the
-RPM spec
-
-For the Win32 with MSVCRT runtime target:
-
-[cols=",,",]
-|===================================================================================================
-|mingw32_bindir |%\{mingw32_prefix}/bin |Location of Windows executables.
-|mingw32_datadir |%\{mingw32_prefix}/share |Shared data used under Windows.
-|mingw32_docdir |%\{mingw32_prefix}/share/doc |Documentation.
-|mingw32_infodir |%\{mingw32_prefix}/share/info |Info files (see note below).
-|mingw32_includedir |%\{mingw32_prefix}/include |Header files used when cross-compiling for Windows.
-|mingw32_libdir |%\{mingw32_prefix}/lib |Windows libraries (see sections below).
-|mingw32_libexecdir |%\{mingw32_prefix}/libexec |
-|mingw32_mandir |%\{mingw32_prefix}/share/man |Man pages (see note below).
-|mingw32_prefix |%\{mingw32_sysroot}/mingw |Windows equivalent of %\{_prefix}, required by MinGW.
-|mingw32_sbindir |%\{mingw32_prefix}/sbin |
-|mingw32_sysconfdir |%\{mingw32_prefix}/etc |Configuration files used when running under Windows.
-|mingw32_sysroot |%\{_prefix}/i686-w64-mingw32/sys-root |Windows system root.
-|===================================================================================================
-
-For the Win64 with MSVCRT runtime target:
-
-[cols=",,",]
-|===================================================================================================
-|mingw64_bindir |%\{mingw64_prefix}/bin |Location of Windows executables.
-|mingw64_datadir |%\{mingw64_prefix}/share |Shared data used under Windows.
-|mingw64_docdir |%\{mingw64_prefix}/share/doc |Documentation.
-|mingw64_infodir |%\{mingw64_prefix}/share/info |Info files (see note below).
-|mingw64_includedir |%\{mingw64_prefix}/include |Header files used when cross-compiling for Windows.
-|mingw64_libdir |%\{mingw64_prefix}/lib |Windows libraries (see sections below).
-|mingw64_libexecdir |%\{mingw64_prefix}/libexec |
-|mingw64_mandir |%\{mingw64_prefix}/share/man |Man pages (see note below).
-|mingw64_prefix |%\{mingw64_sysroot}/mingw |Windows equivalent of %\{_prefix}, required by MinGW.
-|mingw64_sbindir |%\{mingw64_prefix}/sbin |
-|mingw64_sysconfdir |%\{mingw64_prefix}/etc |Configuration files used when running under Windows.
-|mingw64_sysroot |%\{_prefix}/x86_64-w64-mingw32/sys-root |Windows system root.
-|===================================================================================================
-
-For the Win64 with UCRT runtime target:
-
-[cols=",,",]
-|===================================================================================================
-|ucrt64_bindir |%\{ucrt64_prefix}/bin |Location of Windows executables.
-|ucrt64_datadir |%\{ucrt64_prefix}/share |Shared data used under Windows.
-|ucrt64_docdir |%\{ucrt64_prefix}/share/doc |Documentation.
-|ucrt64_infodir |%\{ucrt64_prefix}/share/info |Info files (see note below).
-|ucrt64_includedir |%\{ucrt64_prefix}/include |Header files used when cross-compiling for Windows.
-|ucrt64_libdir |%\{ucrt64_prefix}/lib |Windows libraries (see sections below).
-|ucrt64_libexecdir |%\{ucrt64_prefix}/libexec |
-|ucrt64_mandir |%\{ucrt64_prefix}/share/man |Man pages (see note below).
-|ucrt64_prefix |%\{ucrt64_sysroot}/mingw |Windows equivalent of %\{_prefix}, required by MinGW.
-|ucrt64_sbindir |%\{ucrt64_prefix}/sbin |
-|ucrt64_sysconfdir |%\{ucrt64_prefix}/etc |Configuration files used when running under Windows.
-|ucrt64_sysroot |%\{_prefix}/x86_64-w64-mingw32ucrt/sys-root |Windows system root.
-|===================================================================================================
-
-== Compilation of binaries
-
-In order to build binaries for multiple targets we have to call commands like
-`+./configure+` and `+make+` multiple times (once for each target). If one has
-to write this all out in a spec file then it will lead to duplicate code. To
-reduce the amount of duplication, several RPM macros have been introduced to
-help with the compilation. These macros are `+%mingw_configure+`,
-`+%mingw_cmake+`, `+%mingw_cmake_kde4+`, `+%mingw_qmake_qt4+`,
-`+%mingw_qmake_qt5+` and `+%mingw_make+`
-
-These macros use out of source compilation to build binaries for all the
-targets. Almost all packages support out of source compilation or require
-slight patching. The only known exceptions to date are zlib and openssl.
-Packages which don't support out of source compilation may require a different
-approach like performing everything in the %install phase. If you happen to
-stumble across a package which requires a different approach feel free to
-contact us on the Fedora MinGW mailing list
-
-Some packages need to be built multiple times for each target. Examples of this
-are packages which have to be built once for a static version and once for a
-shared version. Such packages can add a custom suffix to the build directory
-used. Say you've got something like below:
-
-[source, rpm-spec]
-----
- mkdir build_shared
- pushd build_shared
- %{mingw32_configure} --enable-shared
- popd
- mkdir build_static
- pushd build_static
- %{mingw32_configure} --enable-static
- popd
-----
-
-This can be rewritten to something like this:
-
-[source, rpm-spec]
-----
- MINGW_BUILDDIR_SUFFIX=shared %mingw_configure --enable-shared
- MINGW_BUILDDIR_SUFFIX=static %mingw_configure --enable-static
-----
-
-Most packages used the command `+make %{?_smp_mflags}+` to build the package.
-In the MinGW cross compiler framework you have to use
-`+%mingw_make %{?_smp_mflags}+` to build the package for all configured targets.
-As with the `+%mingw_configure+` macro you can also use the
-MINGW_BUILDDIR_SUFFIX environment variable to indicate a custom suffix to the
-build directory used
-
-To install the package the command `+make install DESTDIR=$RPM_BUILD_ROOT+` was
-used in almost all cases. This can be rewritten to
-`+%mingw_make install DESTDIR=$RPM_BUILD_ROOT+` to install the package for all
-configured targets. The environment variable MINGW_BUILDDIR_SUFFIX can also be
-used here.
-
-Some packages require some custom instructions before the files are ready to be
-packaged. Such code can remain as is. However, you may need to duplicate these
-instructions multiple times (for all configured targets).
-
-== Dependencies
-
-If a package contains binaries which depend on a DLL provided by another
-package, these dependencies should be expressed in the form:
-
-....
- mingw32(foo.dll)
-....
-
-where `+foo.dll+` is the name of the DLL. The name must be converted to
-lowercase because Windows binaries contain case insensitive dependencies. The
-form 'mingw32(foo.dll)' should be used for Win32 binaries and the form
-'mingw64(foo.dll)' for Win64 binaries.
-
-Correct dependency generation is done automatically. Packagers should start
-their spec files with this line:
-
-[source, rpm-spec]
-----
- %{?mingw_package_header}
-----
-
-All binary packages should depend on `+mingw32-filesystem+` or
-`+mingw64-filesystem+` (depending on the files in the package).
-
-All specfiles should BuildRequire at least one of these (depending on the
-targets for which you want to build):
-
-[source, rpm-spec]
-----
- BuildRequires:  mingw32-filesystem
- BuildRequires:  mingw64-filesystem
-----
-
-and any other BuildRequires that they need.
-
-Most mingw RPM macros can be assumed to exist in all non-EOL Fedora releases.
-If the package does, however, rely on a newly introduced macro, a versioned
-dependancy on the `+mingw-XX-filesystem+` packages should be used.
-
-== Build architecture
-
-All packages should have:
-
-[source, rpm-spec]
-----
- BuildArch: noarch
-----
-
-unless they contain Fedora native executables. Where using the separate
-packaging approach, the `+BuildArch+` tag must be present in the common
-spec file header. Where using the integrated packaging approach, the
-`+BuildArch+` tag must be present under the %package header for each MinGW
-sub-RPM that is present.
-
-== Libraries (DLLs)
-
-All libraries must be built as DLLs.
-
-Because of the peculiarity of Windows, DLLs are stored in the
-`+%{mingw32_bindir}+` directory, along with a control file in the
-`+%{mingw32_libdir}+` directory. For example, for a library called `+foo+`
-there would be:
-
-[source, rpm-spec]
-----
- %{mingw32_bindir}/foo.dll
- %{mingw32_libdir}/foo.dll.a
-----
-
-The `+foo.dll+` file is the main library, `+foo.dll.a+` is a stub linked to
-applications so they can find the library at runtime. All of these files are
-required in those locations in order to link successfully. The `+.dll+` may
-contain a version number although not always (e.g., `+foo-0.dll+`).
-
-=== Do not use %\{mingw32_bindir}/* or %\{mingw32_libdir}/* in %files section
-
-The `+%files+` section must list DLLs and import libraries separately. Packages
-must NOT use `+%{mingw32_bindir}/*+` or `+%{mingw32_libdir}/*+`
-
-The reason for this is that libtool is very fragile and will give up on building
-a DLL very easily. Therefore we force the name of the DLL to be listed
-explicitly in the `+%files+` section in order to catch this during RPM builds.
-
-=== Stripping
-
-Libraries and executables should be stripped. This is done correctly and
-automatically if the spec file starts with this line:
-
-[source, rpm-spec]
-----
- %{?mingw_package_header}
-----
-
-=== Debuginfo subpackage
-
-Most binaries contain debugging symbols when the package gets built. To split
-the debugging symbols to a separate debuginfo package (as is done with native
-Fedora packages) the spec file must include these lines:
-
-[source, rpm-spec]
-----
- %{?mingw_package_header}
- [...]
- %{?mingw_debug_package}
-----
-
-The `+%{?mingw_debug_package}+` line must be placed after the
-`+%description tag+`. Otherwise spectool and other RPM tools may fail to
-function.
-
-When using the integrated packaging approach the `+%install+` section must
-also contain a call to the `+%{mingw_debug_install_post}+` macro after any
-binary files have been installed to the virtual root:
-
-[source, rpm-spec]
-----
- %install
- [...]
- %{?mingw_debug_install_post}
-----
-
-== File listing
-
-The MinGW packages are intended to allow developers to compile and test the
-Windows support of their applications. It is furthermore expected that
-developers will build Windows installers (MSIs) for their applications using
-the MinGW package content.
-
-Thus the Fedora MinGW package file listing must include content needed to
-satisfy either build/test usage or the creation of Windows installers.
-
-=== Executables (EXEs)
-
-Most libraries also provide executables. These can include executables which
-can be used to test or showcase the library in question (for example
-gtk3-demo.exe in mingw-gtk3). Other examples are helper executables which are
-used by the library itself internally (for example gspawn-win32-helper.exe in
-mingw-glib2).
-
-Executables which are required for proper functionality of the libraries must be
-packaged in the matching mingw32/mingw64 subpackage. Other optional executables
-targetted at end users should be packaged (for example certtool.exe in GNUTLS).
-Executables targetted at developers are discouraged, but may be packaged in
-optional (dependent) subpackages at a packager's discretion.
-
-=== Files which are already part of native packages
-
-There are various types of files which are simply duplicates of equivalent files
-found in Fedora native packages. These files should not be packaged in the MinGW
-package. The following files don't need to be packaged in the MinGW package when
-their native counterpart already contains them:
-
-* Man pages (`+%{mingw32_mandir}+` / `+%{mingw64_mandir}+` / `+%{ucrt64_mandir}+`)
-* Info files (`+%{mingw32_infodir}+` / `+%{mingw64_infodir}+` / `+%{ucrt64_infodir}+`)
-* Generic documentation (`+%{mingw32_docdir}+` / `+%{mingw64_docdir}+` / `+%{ucrt64_docdir}+`)
-* Autoconf files (`+%{mingw32_datadir}/aclocal+` / `+%{mingw64_datadir}/aclocal+` / `+%{ucrt64_datadir}/aclocal+`)
-* gtk-doc files (`+%{mingw32_datadir}/gtk-doc+` / `+%{mingw64_datadir}/gtk-doc+` / `+%{ucrt64_datadir}/gtk-doc+`)
-
-Note, generic Documentation aimed at end users, as opposed to developers,
-should be included where it is likely that application developers will want
-to bundle it with their Windows installers.
-
-== Converting between separate and integrated packaging
-
-In general it it possible to convert in either direction between the separate
-and integrated packaging approaches. Both approaches result in the exact same
-binary RPMs for MinGW content, only differing in their source RPM specfile.
-
-To convert from separate to integrated packaging
-
-* Ensure the existing native software package has either the same (or newer)
-  version number as the existing MinGW package.
-* Add MinGW support to the existing native package spec file
-* If both the native and existing MinGW packages were at the same version,
-  ensure the release number of the native package is newer than any previous
-  build of the MinGW package.
-* Build the new native package with MinGW support
-* Retire the separate MinGW package
-
-To convert from integrated to separate packaging
-
-* Go through the new package review process for the separate MinGW package,
-  ensuring it is the same version number as the existing integrated package
-* Import the separate MinGW package to dist-git but don't build it.
-* Drop MinGW support from the existing native package spec file
-* Build the native package without MinGW support
-* Ensure the separate MinGW package has a newer release number than any existing
-  MinGW binary sub-RPMs built from the native package
-* Build the separate MinGW package
-
-In both cases the upgrade experience should be transparent to users installing
-and updating Fedora deployments.
-
-It is recommended that such conversions only be performed in Rawhide. If there
-is need to do a conversion from integrated to separate packaging in a stable
-release stream, a single Bohdi update must include both the native and mingw
-package builds.
-
-== Disabling MinGW packages
-
-When using the integrated packaging approach it **MUST** be possible to disable
-the build of MinGW sub-RPMs, and the build **MUST** be disabled by default
-except for the Fedora distribution target. This ensures that the native package
-can still be built in derivative distros, such as RHEL, where the MinGW
-toolchains not included. This is achieved by including a conditional near
-the top of the specfile:
-
-[source, rpm-spec]
-----
-%if 0%{?fedora}
-%bcond_without mingw
-%else
-%bcond_with mingw
-%endif
-----
-
-and then wrapping all MinGW related `+%package+` / `+%files` definitions and
-relevant `+%build+` or `+%install+` commands in a conditional check:
-
-[source, rpm-spec]
-----
-%if %{with mingw}
-%package -n mingw32-example
-Summary: %{summary}
-BuildArch: noarch
-[...]
-%endif
-----
-
-== Example Integrated Package Specfile
-
-[source, rpm-spec]
-----
-%if 0%{?fedora}
-%bcond_without mingw
-%else
-%bcond_with mingw
-%endif
-
-Name: example
-Version: 1.0.0
-Release: 1%{?dist}
-Summary: Example library
-
-License: LGPL-2.1-or-later
-URL: https://fedoraproject.org
-Source: https://fedoraproject.org/example-%{version}.tar.bz2
-
-BuildRequires: gcc
-BuildRequires: binutils
-BuildRequires: gettext
-BuildRequires: zlib
-
-%if %{with mingw}
-BuildRequires: mingw32-filesystem
-BuildRequires: mingw32-gcc
-BuildRequires: mingw32-binutils
-BuildRequires: mingw32-gettext
-BuildRequires: mingw32-win-iconv
-BuildRequires: mingw32-zlib
-
-BuildRequires: mingw64-filesystem
-BuildRequires: mingw64-gcc
-BuildRequires: mingw64-binutils
-BuildRequires: mingw64-gettext
-BuildRequires: mingw64-win-iconv
-BuildRequires: mingw64-zlib
-%endif
-
-%description
-Example library.
-
-%package devel
-Summary: Example library development package
-...
-
-%description devel
-Example library development headers and library.
-
-%if %{with mingw}
-# If a package maintainer wishes to bundle static libraries then they
-# can be placed in -static subpackages. Otherwise, the -static subpackages
-# can be dropped
-
-# Win32
-%package -n mingw32-example
-Summary: MinGW compiled example library for the Win32 target
-BuildArch: noarch
-
-%description -n mingw32-example
-MinGW compiled example library for the Win32 target.
-
-%package -n mingw32-example-static
-Summary: Static version of the MinGW Win32 compiled example library
-Requires: mingw32-example = %{version}-%{release}
-
-%description -n mingw32-example-static
-Static version of the MinGW Win32 compiled example library.
-
-# Win64
-%package -n mingw64-example
-Summary: MinGW compiled example library for the Win64 target
-
-%description -n mingw64-example
-MinGW compiled example library for the Win64 target.
-BuildArch: noarch
-
-%package -n mingw64-example-static
-Summary: Static version of the MinGW Win64 compiled example library
-Requires: mingw64-example = %{version}-%{release}
-
-%description -n mingw64-example-static
-Static version of the MinGW Win64 compiled example library.
-
-%{?mingw_debug_package}
-%endif
-
-
-%prep
-%autosetup -p1 -n example-%{version}
-
-
-%build
-
-%define _configure ../../configure
-
-mkdir -p build/native
-cd build/native
-%configure ...
-%make_build
-cd ../..
-
-%if %{with mingw}
-%mingw_configure --enable-static --enable-shared --enable-foo
-%mingw_make_build
-%endif
-
-%install
-cd build/native
-%make_install
-
-%find_lang example
-cd ../..
-
-%if %{with mingw}
-%mingw_make_install
-
-%mingw_find_lang example
-%endif
-
-%files
-%{_libdir}/libexample.so.*
-
-%files devel
-%{_libdir}/libexample.so
-%{_libdir}/pkgconfig/example.pc
-%{_includedir}/example/
-
-# Static subpackages are optional (as mentioned earlier)
-
-%if %{with mingw}
-# Win32
-%files -n mingw32-example -f mingw32-example.lang
-%{mingw32_bindir}/libexample-0.dll
-%{mingw32_includedir}/example/
-%{mingw32_libdir}/libexample.dll.a
-%{mingw32_libdir}/pkgconfig/example.pc
-
-%files -n mingw32-example-static
-%{mingw32_libdir}/libexample.a
-
-# Win64
-%files -n mingw64-example -f mingw64-example.lang
-%{mingw64_bindir}/libexample-0.dll
-%{mingw64_includedir}/example/
-%{mingw64_libdir}/libexample.dll.a
-%{mingw64_libdir}/pkgconfig/example.pc
-
-%files -n mingw64-example-static
-%{mingw64_libdir}/libexample-0.a
-%endif
-
-%changelog
-* Sun Apr 15 2012 Erik van Pienbroek <epienbro@fedoraproject.org> - 1.0.0-1
-- Initial release
-----
-
-== Example Separate Package Specfile
-
-The separate package specfile essentially extracts all the content within the
-`+%{with mingw}+` conditionals from the previous example, and puts it into a
-standalone specfile.
-
-[source, rpm-spec]
-----
-%{?mingw_package_header}
-
-Name: mingw-example
-Version: 1.0.0
-Release: 1%{?dist}
-Summary: MinGW compiled example library
-
-License: LGPL-2.1-or-later
-URL: https://fedoraproject.org
-Source: https://fedoraproject.org/example-%{version}.tar.bz2
-
-BuildArch: noarch
-
-BuildRequires: mingw32-filesystem
-BuildRequires: mingw32-gcc
-BuildRequires: mingw32-binutils
-BuildRequires: mingw32-gettext
-BuildRequires: mingw32-win-iconv
-BuildRequires: mingw32-zlib
-
-BuildRequires: mingw64-filesystem
-BuildRequires: mingw64-gcc
-BuildRequires: mingw64-binutils
-BuildRequires: mingw64-gettext
-BuildRequires: mingw64-win-iconv
-BuildRequires: mingw64-zlib
-
-
-%description
-MinGW compiled example library.
-
-
-# If a package maintainer wishes to bundle static libraries then they
-# can be placed in -static subpackages. Otherwise, the -static subpackages
-# can be dropped
-
-# Win32
-%package -n mingw32-example
-Summary: MinGW compiled example library for the Win32 target
-
-%description -n mingw32-example
-MinGW compiled example library for the Win32 target.
-
-%package -n mingw32-example-static
-Summary: Static version of the MinGW Win32 compiled example library
-Requires: mingw32-example = %{version}-%{release}
-
-%description -n mingw32-example-static
-Static version of the MinGW Win32 compiled example library.
-
-# Win64
-%package -n mingw64-example
-Summary: MinGW compiled example library for the Win64 target
-
-%description -n mingw64-example
-MinGW compiled example library for the Win64 target.
-
-%package -n mingw64-example-static
-Summary: Static version of the MinGW Win64 compiled example library
-Requires: mingw64-example = %{version}-%{release}
-
-%description -n mingw64-example-static
-Static version of the MinGW Win64 compiled example library.
-
-
-%{?mingw_debug_package}
-
-
-%prep
-%autosetup -p1 -n example-%{version}
-
-
-%build
-%mingw_configure --enable-static --enable-shared --enable-foo
-%mingw_make_build
-
-
-%install
-%mingw_make_install
-
-# Libtool files don't need to be bundled
-find %{buildroot} -name "*.la" -delete
-
-%mingw_find_lang example
-
-
-# Note: there should be no %%files section for the main package!
-
-# Static subpackages are optional (as mentioned earlier)
-
-# Win32
-%files -n mingw32-example -f mingw32-example.lang
-%{mingw32_bindir}/libexample-0.dll
-%{mingw32_includedir}/example/
-%{mingw32_libdir}/libexample.dll.a
-%{mingw32_libdir}/pkgconfig/example.pc
-
-%files -n mingw32-example-static
-%{mingw32_libdir}/libexample.a
-
-# Win64
-%files -n mingw64-example -f mingw64-example.lang
-%{mingw64_bindir}/libexample-0.dll
-%{mingw64_includedir}/example/
-%{mingw64_libdir}/libexample.dll.a
-%{mingw64_libdir}/pkgconfig/example.pc
-
-%files -n mingw64-example-static
-%{mingw64_libdir}/libexample-0.a
-
-
-%changelog
-* Sun Apr 15 2012 Erik van Pienbroek <epienbro@fedoraproject.org> - 1.0.0-1
-- Initial release
-----
diff --git a/guidelines/modules/ROOT/pages/Mono.adoc b/guidelines/modules/ROOT/pages/Mono.adoc
deleted file mode 100644
index 454f402..0000000
--- a/guidelines/modules/ROOT/pages/Mono.adoc
+++ /dev/null
@@ -1,127 +0,0 @@
-= Mono Packaging Guidelines
-
-== File Locations and Architectures
-
-For a while, Fedora considered mono packages to be architecture-specific, and installed assemblies to %\{_libdir}. However, after discussions with upstream, we now consider mono packages to be architecture (and platform) independent. This means that mono packages should be correctly installed into the GAC in in %\{_monogacdir} or installed into /usr/lib/PACKAGENAME.
-
-As a notable exception, any ELF binary libraries generated in a mono package must be correctly installed into %\{_libdir}, because these files are architecture-specific.
-
-Also, even though we consider mono packages to be architecture independent, they must not be marked as "noarch". Although the assemblies are the same, the files may differ due to strings referring to the build architecture.
-
-In addition, because some architectures simply do not support mono, every mono package (either a library or a mono-using application) must include
-
-....
-ExclusiveArch: %{mono_arches}
-....
-
-The `+%mono_arches+` must be used instead of a list of architectures in order to facilitate changes to the architecture list.
-
-== gacutil in a spec file
-
-gacutil is used to register dlls with mono (think of it as installing a library - which it is!).
-
-When packaging *any* mono application which generates libraries which gacutil then registers (say mysql-connector-net), you need something like the following in the spec file
-
-....
-%install
-mkdir -p %{buildroot}/%{_monogacdir}
-gacutil -i bin/mono-1.0/release/MySql.Data.dll -f -package mysql-connector-net -root %{buildroot}/usr/lib
-
-%files
-%{_monogacdir}/MySql.Data
-%{_monodir}/mysql-connector-net/
-....
-
-gacutil format
-
-....
--i = input dll
--f = check references
--package = package name
--root = build root
-....
-
-== RPMS and source
-
-Don't build RPMS against built from source versions of mono. It will work for you but probably not for other users!
-
-While you may get away with recompiling the source for part of the overall package (such as gnome-panel is part of gnome or evolution-data-server is part of evolution) for other programs, you should not attempt this with Mono.
-
-If you're going to use the source, you *MUST* remove the RPMS first.
-
-Compiling mono is not a trivial matter and may not even work (when you download the source, you must also _make get-monolite-latest_ which grabs a version of the corelib and mcs which are need for compiling the main C# compilers - the monolite-latest does not always work and you end up without a working copy of Mono.
-
-== rpmlint and mono packages
-
-rpmlint is a program that checks packages for common problems. For mono packages, some of the rpmlint messages can be disregarded.
-
-Mono installs binaries in %\{_libdir}//bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour). It will also not recognise that mono libraries are not ELF format and may generate errors on this as well.
-
-rpmlint will also pick up on any .pc file installed in the rpm (see below).
-
-== -devel packages
-
-Mono packages *must* package .pc files in a -devel package, even if that is the only file that will be included. If we were to permit .pc files in non-devel packages, then we'll have non-devel packages that depend on -devel packages, inflating the install needlessly.
-
-== Empty debuginfo
-
-Sometimes building mono packages results in an empty debuginfo sub package, one without any files to install. See Packaging/Debuginfo
-
-== Incorrect Behaviours
-
-=== Distributing Prebuilt Assemblies
-
-Because mono .dlls are generally architecture independent, upstream may ship tarballs which install precompiled .dlls and .exes. All packages *must* build from source so the packager needs to watch out for these tarballs and be certain not to use them. (This can sneak in during upgrades as well, so the packager has to make sure they're building from source every time the tarball is changed.)
-
-=== Distributing .DLLs from other projects
-
-The Mono project's website makes
-https://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs[this suggestion]
-
-....
-Sometimes developers might want to distribute a library to other developers but they might not have a library that is API stable or has not matured enough over time to guarantee the backwards-compatibility of their libraries or they are not willing to maintain multiple packages of the various versions for users.
-[...] 
-To solve this problem, we recommend that:
-
-* The library developer ships a properly configured pkg-config file.
-* The library consumers include an "update-libraries" target on their Makefile that will import the latest version of a library from a system directory into their application source code distribution.
-* The library consumers ship this library as part of their package.
-....
-
-This suggestion may make it easier for applications targetting unstable library APIs but it is *_extremely poor practice_*. Using libraries in this manner has all the same problems as linking with static libraries, most notably that the application can suffer from security holes in the library long after it is fixed upstream. Mono applications in Fedora cannot include upstream DLLs (even if they are compiled from source). This is a blocker issue and *must* be fixed.
-
-There are several techniques for detecting the presence of these libraries, none of them fool proof. If you know of a better method, please add it:
-
-1. Upstream tarball contains .dlls that were not rebuilt from source contained in the package.
-2. Look through the installed .dlls for any that have the same name as system .dlls or are suspiciously out of place (Package is myDiary and contains mysql.dll, sqlite.dll, and gtk-sharp.dll)
-3. Source directories look odd:
-
-....
-PKGNAME/
-src/
-data/
-libs/
-gtk-sharp/
-atk-sharp/
-....
-
-=== Redefining _libdir
-
-Packagers should avoid redefining _libdir in their spec file. Redefinition of this macro will cover up problems instead of helping fix them. Packagers should:
-
-1. Identify which directories the files should install into according to the xref:index.adoc[Packaging Guidelines] .
-2. Patch the packages build scripts to install to those locations.
-3. Identify places where the package has hardcoded the old locations instead of the new ones and fix those.
-4. Either report the issues to upstream or submit patches. Note that upstream projects are generally receptive to patches that allow package builders to redefine install locations at build time -- less receptive to patches which change upstream's hardcoded defaults to our hardcoded defaults.
-
-=== Defining target
-
-Was done for a brief period when we attempted to package mono apps as noarch. It was not necessary then (the actual fix was to stop using AC_CANONICAL_* in the configure.ac file) and it is definitely not needed now that we are no longer building noarch mono packages.
-
-== Glossary
-
-* *AOT*: Ahead Of Time. This usually refers to the ELF .so file that is the result of ahead of time compiling an assembly. AOTs are dependent on the assemblies they were generated from for certain data (unlike their equivalents in python and java). AOTs are created explicitly, not automatically.
-* *Assembly*: An assembly is the EXE or DLL file created by compiling a mono application. These are not the same as EXE's or DLL's created by compiling a C or C++ program on Windows. An assembly contains CIL code rather than machine code.
-* *CIL*: CIL stands for Common Intermediate Language. It is roughly equivalent to java bytecode and is generally portable across architectures. Some programming practices (calling out to native system libraries) can lead to CIL code that will not run on all architectures.
-* *GAC*: GAC stands for Global Assembly Cache. It is a machine-wide .NET assemblies cache.
-* *Glue Libraries*: Libraries which bridge a system library written in C or C++ with Mono. These wrappers are separate different than AOTs.
diff --git a/guidelines/modules/ROOT/pages/Naming.adoc b/guidelines/modules/ROOT/pages/Naming.adoc
deleted file mode 100644
index 83637f8..0000000
--- a/guidelines/modules/ROOT/pages/Naming.adoc
+++ /dev/null
@@ -1,492 +0,0 @@
-= Naming Guidelines
-
-[NOTE]
-.Versioning guidelines have moved
-====
-This document previously contained information on both naming and versioning.
-The versioning guidelines are now at xref:Versioning.adoc[Packaging:Versioning].
-====
-
-== Common Character Set for Package Naming
-
-While Fedora is an international community,
-for consistency and usability,
-there needs to be a common character set for package naming.
-
-Specifically,
-all Fedora packages must be named using only the following ASCII characters.
-These characters are displayed here:
-
-....
-abcdefghijklmnopqrstuvwxyz
-ABCDEFGHIJKLMNOPQRSTUVWXYZ
-0123456789-._+
-....
-
-But do check <<Separators>> for additional restrictions
-on using the `+-._++` characters.
-
-=== General Naming
-
-Package names SHOULD be in lower case
-and use dashes in preference to underscores.
-You can take some cues from the name of the upstream tarball,
-the project name from which this software came,
-and the name which has been used for this package
-by other distributions/packagers in the past.
-You can also request guidance from the upstream developers.
-Do not just blindly follow those examples, however,
-as package names SHOULD strive to be consistent
-within Fedora more than consistent between distributions.
-
-Additionally, it is possible that the upstream name does not fall into the
-<<Common Character Set for Package Naming>>.
-If this is the case, refer to:
-<<When Upstream Naming is outside of the specified character set>>.
-
-Also remember to check whether
-the type of package you are packaging
-has specific rules for naming.
-<<Font Packages>>
-and the various sorts of
-<<Addon Packages>>,
-for instance.
-
-=== Separators
-
-When naming packages for Fedora,
-the maintainer MUST use the dash `+-+` as the delimiter for name parts.
-The maintainer MUST NOT use an underscore `+_+`, a plus `+++`, or a period `+.+` as a delimiter.
-Version numbers used in compat libraries do not need to omit the dot `+.+`
-or change it into a dash `+-+`
-(see <<Multiple packages with the same base name>>
-for more info on this case).
-
-There are a few exceptions to the no underscore `+_+` rule:
-
-* httpd, pam, and SDL addon packages are excluded,
-  refer to "`<<_httpd_pam_and_sdl,Addon Packages (httpd, pam, and SDL)>>`".
-* packages that are locale specific,
-  and use the locale in the name are excluded,
-  refer to "`<<_locales,Addon Packages (locales)>>`".
-* Compat packages where the base package name ends in a digit,
-  refer to "`<<Multiple packages with the same base name>>`".
-* packages where the upstream name naturally contains an underscore
-  are excluded from this. Examples of these packages include:
-+
-....
-arptables_jf
-dhcpv6_client
-java_cup
-knm_new
-libart_lgpl
-lm_sensors
-microcode_ctl
-nss_db
-nss_ldap
-sg3_utils
-tcp_wrappers
-....
-
-If in doubt, ask on devel@lists.fedoraproject.org.
-
-=== When Upstream Naming is outside of the specified character set
-
-Fedora recognizes that the task of converting text
-to the specified ASCII character set (aka transliteration) is difficult.
-Accordingly, when the upstream name is outside of the specified ASCII character set,
-the Fedora package maintainer SHOULD first contact the upstream for that software
-and ask them for a transliteration of the name for Fedora to use.
-
-If (and only if) the upstream is unable,
-unwilling, or unavailable
-to provide a transliterated name,
-the Fedora packager must choose
-to either perform their own transliteration,
-or withdraw the package from consideration in Fedora.
-
-When deciding how to transliterate a package name,
-the Fedora packager SHOULD look to see what (if any)
-other distributions have done for that package's name,
-and take that into account.
-
-=== Extra Provides
-
-Transliterated packages MAY Provide:
-the original, non-transliterated name,
-but are not required to do so.
-
-== Conflicting Package Names
-
-Conflicting package names,
-even if they differ by case alone,
-are not allowed.
-Please see
-xref:Conflicts.adoc#_conflicting_package_names[Packaging:Conflicts#Conflicting Package Names]
-for more details.
-
-[#multiple]
-== Multiple packages with the same base name
-
-For many reasons, it is sometimes advantageous
-to keep multiple versions of a package in Fedora
-to be installed simultaneously.
-When doing so, the package name MUST reflect this fact.
-One package SHOULD use the base name
-(with no version information).
-All other packages derived from it MUST include the base name
-suffixed by either:
-
-* The package version, which SHOULD include the periods present in the original version.
-** If the base package name ends with a digit,
-   a single underscore (`+_+`) MUST be appended to the name,
-   and the version MUST be appended to that,
-   in order to avoid confusion over where the name ends and the version begins.
-** If the base package name does not end with a digit,
-   the version MUST be directly appended to the package name with no intervening separator.
-* a hyphen (`+-+`) followed by a descriptive suffix
-  such as "stable"
-  which provides some indication
-  as to the nature of the packaged version.
-
-*Examples:*
-
-* The python-sqlalchemy package occasionally has multiple versions in Fedora
-  for backwards compatibility.
-  The most current version of python-sqlalchemy is named
-  `+python-sqlalchemy+`
-  and an older supported version is
-  `+python-sqlalchemy0.5+`.
-  No delimiter is used in this situation.
-* The most current version of the v8 package is named `+v8+`.
-  In order to package version "3.13",
-  the package MUST be named `+v8_3.13+`.
-
-Please also note that strings such as "-latest"
-can often become misleading over time
-if the package (in *all* active Fedora releases)
-is not kept updated with the latest upstream version.
-
-=== Documentation Packages with Embedded OS versioning
-
-Documentation packages
-(as approved by the Fedora Documentation Project)
-can be named with the OS version number in the package name
-to allow parallel installation of multiple versions,
-in cases where the documentation is specific to a release of Fedora
-and there is value in having multiple versions simultaneously installed.
-
-== Case Sensitivity
-
-In Fedora packaging, the maintainer uses their best judgement when considering how to name the package.
-While case sensitivity is not a mandatory requirement,
-case SHOULD only be used where necessary.
-Keep in mind to respect the wishes of the upstream maintainers.
-If they refer to their application as "ORBit",
-you SHOULD use `+ORBit+` as the package name,
-and not `+orbit+`.
-However, if they do not express any preference of case,
-you SHOULD default to lowercase naming.
-
-The exception to this is for perl module packaging.
-The CPAN Group and Type SHOULD be capitalized in the name,
-as if they were proper nouns.
-(Refer to "`<<_perl_modules,Addon Packages (Perl modules)>>`" for details.)
-
-== Renaming/replacing existing packages
-
-See: xref:index.adoc#renaming-or-replacing-existing-packages[Packaging:Guidelines#Renaming/Replacing Existing Packages]
-
-== Documentation Subpackages
-
-Large documentation files SHOULD go in a subpackage.
-This subpackage must be named with the format: `+%{name}-doc+` .
-The definition of large is left up to the packager's best judgement,
-but is not restricted to size.
-Large can refer to either size or quantity of files.
-
-== Font Packages
-
-Packages containing fonts must be named
-`+[foundryname-]projectname[-fontfamilyname]-fonts+`,
-in lowercase.
-
-=== Clarifications
-
-1.  For Fedora purposes a “foundry” is an entity that publishes a set of fonts with consistent font QA rules. Thus a generic hosting service such as http://www.sf.net[Sourceforge] is not a foundry, but the http://openfontlibrary.org/[Open Font Library] is.
-2.  It is good practice to contract _foundryname-_ in a short prefix.
-3.  The _foundryname-_ prefix can optionally be skipped:
-* for entities that never released more than one font family, or
-* when the font project and the publishing entity are one and the same.
-4.  If _projectname_ or _foundryname_ are repeated in _fontfamilyname_, they can be dropped from _fontfamilyname_.
-5.  When _foundryname_, _projectname_ or _fontfamilyname_ contain the _font_ or _fonts_ affix, this affix should be dropped from themfootnote:[To avoid _foofont-fonts_ packages.].
-6.  _-fontfamilyname_ should not be included in the srpm name of a package that includes several different font families.
-7.  If any element of the naming contains spaces, they should be replaced by “-”.
-8.  The use of the _-fonts_ suffix is not dependant on the actual number of font files in the package.
-
-When in doubt, ask the https://fedoraproject.org/wiki/Fonts_SIG_mailing_lists[mailing list] for clarification.
-
-== Addon Packages
-
-If a package is considered an "addon" package
-that enhances or adds functionality
-to an existing Fedora package
-without being useful on its own, its name SHOULD reflect this fact.
-
-The new package ("child") SHOULD prepend
-the "parent" package in its name,
-in the format: `+%{parent}-%{child}+`.
-
-*Examples:*
-
-....
-gnome-applet-netmon (netmon applet for gnome, relies on gnome)
-php-adodb (adodb functionality for php, relies on php)
-python3-twisted (the twisted module for python3, relies on python3)
-xmms-cdread (direct cd read functionality for xmms, relies on xmms)
-....
-
-When the addon package is a language binding,
-note that the language itself is always the parent.
-Thus, a lua binding for the "randomdb" database would be
-`+lua-randomdb+`,
-not `+randomdb-lua+`.
-Also note that some packages may have grandfathered names
-using the opposite ordering.
-
-There are some exceptions to this general addon package naming policy,
-and they are noted below.
-
-=== httpd, pam, and SDL
-
-Packages that rely on Apache httpd, pam, or SDL
-as a parent use a slightly different naming scheme.
-pam and SDL addons use the format: `+%{parent}_%{child}+`,
-with an underscore `+_+` as a delimiter.
-Apache httpd addons use the format: `+mod_%{child}+`,
-with an underscore `+_+` as a delimiter.
-This naming scheme is usually the same as used for the source tarball name.
-
-*Examples:*
-
-....
-mod_perl (Perl components for Apache httpd, relies on httpd)
-pam_krb5 (krb5 components for pam, relies on pam)
-SDL_gfx (Additional graphics components for SDL, relies on SDL)
-SDL_ttf (TrueType font rendering support for SDL, relies on SDL)
-....
-
-=== emacs components
-
-Packages of emacs add-on components
-(code that adds additional functionality to emacs)
-SHOULD have a name that takes into account the upstream name
-of the emacs component by being called `+emacs-$NAME+`.
-
-*Examples:*
-
-....
-emacs-auctex (auctex component for GNU Emacs)
-emacs-deferred (deferred component for GNU Emacs)
-emacs-flycheck (flycheck component for GNU Emacs)
-....
-
-=== Erlang modules
-
-Packages of Erlang modules
-(thus they rely on Erlang as a parent)
-have their own naming scheme.
-They SHOULD take into account the upstream name of the Erlang module.
-This makes a package name format of `+erlang-$NAME+`.
-When in doubt, use the name of the module
-that you use when importing it into a script.
-
-*Example:*
-
-....
-erlang-esdl (Erlang module named esdl)
-....
-
-=== GAP packages
-
-See the xref:GAP.adoc#_naming[GAP guidelines] for the proper naming of GAP addon packages.
-
-=== Gnome shell extensions
-
-Packages that extend gnome shell SHOULD begin
-with the prefix `+gnome-shell-extension-+`.
-In particular, this prefix SHOULD NOT be pluralized
-(i.e., it SHOULD NOT be `+gnome-shell-extensions+`).
-
-=== GStreamer plugins
-
-Packages that extend GStreamer SHOULD begin
-with the prefix `+gstreamer1-plugin-+`.
-In particular, this prefix SHOULD NOT be pluralized
-(i.e., it SHOULD NOT be `+gstreamer1-plugins+`)
-unless it is a collection of plugins
-(i.e., `+gstreamer1-plugins-good+`).
-
-=== LibreOffice extensions
-
-Packages of LibreOffice extensions
-(thus they rely on LibreOffice as a parent)
-have their own naming scheme.
-They must take into account the upstream name
-of the LibreOffice extension.
-This makes a package name format of `+libreoffice-$NAME+`.
-
-=== Locales
-
-If a package adds a locale to an existing parent package,
-then it can use an underscore in the locale.
-
-*Examples:*
-
-....
-ttfonts-zh_TW (adds zh_TW locale fonts in ttfonts family)
-ttfonts-zh_CN (adds zh_CN locale fonts in ttfonts family)
-....
-
-=== Lua modules
-
-It is common that multiple versions of Lua are packaged,
-and each may have corresponding module packages.
-Of course the base Lua packages of course MUST follow the relevant
-xref:#multiple[naming guidelines]
-resulting in package names such as `+lua5.1+`.
-
-The module packages SHOULD carry the name
-of the corresponding base Lua package
-(as mandated by the xref:#multiple[relevant guidelines])
-as a prefix.
-Some examples:
-
-[cols=",,",]
-|=============================================
-| module name |base lua version |package name
-| argparse |(default) | `+lua-argparse+`
-| argparse | 5.1 | `+lua5.1-argparse+`
-| sql | 5.2 | `+lua5.2-sql+`
-|=============================================
-
-
-=== NGINX modules
-
-Packages of NGINX modules SHOULD begin
-with the prefix `+nginx-mod-+`.
-In particular, this prefix SHOULD NOT be pluralized
-(i.e., it SHOULD NOT be `+nginx-mods+`).
-Some upstream projects may use `+module+` as a
-prefix, and this should be accounted for and
-replaced accordingly in the package name.
-
-=== OBS Studio plugins
-
-Packages of OBS Studio plugins SHOULD begin
-with the prefix `+obs-studio-plugin-+`.
-In particular, this prefix SHOULD NOT be pluralized
-(i.e., it SHOULD NOT be `+obs-studio-plugins+`).
-
-=== OCaml modules
-
-OCaml modules, libraries and syntax extensions
-SHOULD be named `+ocaml-foo+`.
-Examples include: `+ocaml-extlib+`, `+ocaml-ssl+`.
-
-This naming does not apply to applications written in OCaml,
-which can be given their normal name.
-Examples include: `+mldonkey+`, `+virt-top+`, `+cduce+`
-
-=== Perl modules
-
-Packages of Perl modules
-(thus they rely on Perl as a parent)
-use a slightly different naming scheme.
-They SHOULD be named `+perl-CPANDIST+`
-where `+CPANDIST+` is the name of the packaged CPAN module distribution
-(which is almost always also the unit of Perl module packaging).
-In the rare cases when a CPAN module distribution needs to be split
-into smaller subpackages
-e.g., due to dependencies,
-the extra subpackages SHOULD be named `+perl-CPANDIST-Something+`.
-
-*Examples:*
-
-....
-perl-Archive-Zip (Archive-Zip is the CPAN distribution name)
-perl-Cache-Cache (Cache-Cache is the CPAN distribution name)
-....
-
-=== PHP modules
-
-For details on the PHP naming scheme, see xref:PHP.adoc#_naming_scheme[Naming scheme].
-
-=== Python modules
-
-Naming of Python modules is fully covered
-in the  xref:Python.adoc#_naming[Naming section]
-of the Python Packaging Guidelines.
-
-In short:
-The package name SHOULD reflect the upstream name of the Python module,
-and SHOULD generally take into account the name of the module
-used when importing it in Python scripts.
-This name will be prefixed depending on the type of the package.
-
-* A built (i.e. non-SRPM) package for a _Python library_
-MUST be named with the prefix `+python3-+`.
-* A source package containing primarily a _Python library_
-MUST be named with the prefix `+python-+`.
-
-The character `+++` is reserved for
-xref:Python.adoc#_extras[Extras].
-
-==== Python2 binary package naming
-
-Python 2 binary packages MUST be named using a `+python2-+` prefix.
-Note that Python 2 is deprecated in Fedora and requires an explicit exception.
-
-=== R modules
-
-Packages of R modules
-(thus they rely on R as a parent)
-have their own naming scheme.
-They SHOULD take into account the upstream name of the R module.
-This makes a package name format of `+R-$NAME+`.
-When in doubt, use the name of the module that you type to import it in R.
-
-*Examples:*
-
-....
-R-mAr (R module named mAr)
-R-RScaLAPACK (R module named RScaLAPACK)
-R-waveslim (R module named waveslim)
-....
-
-=== Sugar Activities
-
-The name for all packaged Sugar activities must be prefixed with `+sugar-+`.
-For more details, see xref:SugarActivityGuidelines.adoc[Packaging/SugarActivityGuidelines].
-
-=== Tcl/Tk extensions
-
-The name for all packaged Tcl/Tk extensions must be prefixed with `+tcl-+`.
-This rule applies even for Tcl/Tk packages
-that are already prefixed with `+tcl+` in the name.
-For more details, see xref:Tcl.adoc#_naming_conventions[Packaging/Tcl#NamingConventions].
-
-=== TeX
-
-As Fedora has switched TeX environments in the past,
-TeX packages SHOULD not be named after the TeX environment
-(TeX Live or teTeX)
-but instead SHOULD carry the prefix `+tex-+`.
-
-== Authorship
-
-The original author of these guidelines was
-https://fedoraproject.org/wiki/TomCallaway[Tom 'spot' Callaway].
-They are now maintained by the
-https://fedoraproject.org/wiki/Packaging_Committee[Packaging Committee]
-with input from the Fedora community.
diff --git a/guidelines/modules/ROOT/pages/Node.js.adoc b/guidelines/modules/ROOT/pages/Node.js.adoc
deleted file mode 100644
index 6749664..0000000
--- a/guidelines/modules/ROOT/pages/Node.js.adoc
+++ /dev/null
@@ -1,378 +0,0 @@
-= Node.js Packaging Guidelines
-
-The upstream Node.js stance on https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/[global library packages] is that they are ".. best avoided if not needed."  In Fedora, we take the same stance with our nodejs packages.  You can provide a package that uses nodejs, but you should bundle all the nodejs libraries that are needed.
-
-== What to Package
-
-* The interpreter, development headers/libraries, and the assorted tools to manage project-level installations.
-** Examples: nodejs, npm, yarn
-* Packages that provide applications that users would want to use in their shell.
-** Examples: uglify
-
-== Naming Guidelines
-
-* Application packages that mainly provide tools (as opposed to libraries) that happen to be written for Node.js must follow the general xref:Naming.adoc[Naming Guidelines] instead.
-
-* The name of a Node.js extension/library package must start with _nodejs-_ then the upstream name or name used in the npm registry. For example: _nodejs-foomodule_. While it is uncommon for a package's name to contain _node_, if it does, you should still add the nodejs prefix. For instance, the npm registry contains a _uuid_ and a _node-uuid_ module, which would need to be named _nodejs-uuid_ and _nodejs-node-uuid_, respectively.
-
-== BuildRequires
-
-To build a package that is a nodejs module, bundles or uses nodejs modules, or needs nodejs for building or testing, you need to have:
-
-....
-BuildRequires: nodejs-devel
-....
-
-== Macros
-
-The following macros are defined for you:
-
-[cols=",,",options="header",]
-|=================================================================================================================================================================================================================
-|Macro |Normal Definition |Notes
-|__nodejs |%\{_bindir}/node |The Node.js interpreter
-|nodejs_version |e.g. 0.9.5 |The currently installed version of Node.js.
-|nodejs_sitelib |%\{_prefix}/lib/node_modules |Where Node.js modules written purely in JavaScript are installed
-|nodejs_sitearch |%\{_prefix}/lib/node_modules |Where native C++ Node.js modules are installed
-|nodejs_symlink_deps |%\{_prefix}/lib/rpm/nodejs-symlink-deps |See <<Symlinking Dependencies>> below.
-|nodejs_fixdep |%\{_prefix}/lib/rpm/nodejs-fixdep |See <<Correcting Dependencies>> below.
-|nodejs_arches |%\{ix86} x86_64 %\{arm} |See #ExclusiveArch. This macro is provided by `+redhat-rpm-config+` in F19+ so it works with Koji properly.
-|nodejs_default_filter |%global __provides_exclude_from ^%\{nodejs_sitearch}/.*\\.node$ |Filters unwanted provides from native modules. See <<Filtering Unwanted Provides>> below.
-|=================================================================================================================================================================================================================
-
-These macros are provided by the _nodejs-packaging_ package.
-
-During `+%install+` or when listing `+%files+` you can use the `+%nodejs_sitelib+` or `+%nodejs_sitearch+` macro to specify where the installed modules are to be found. For instance:
-
-....
-%files
-# A pure JavaScript node module
-%{nodejs_sitelib}/foomodule/
-# A native node module
-%{nodejs_sitearch}/barmodule/
-....
-
-Using this macro instead of hardcoding the directory in the specfile ensures your spec remains compatible with the installed Node.js version even if the directory structure changes radically (for instance, if `+%nodejs_sitelib+` moves into `+%{_datadir}+`).
-
-== ExclusiveArch
-
-The V8 JavaScript runtime used by Node.js uses a Just-in-Time (JIT) compiler that is specially tuned to individual architectures, and must be manually ported to any new architectures that wish to support it. Node.js packages must include an ExclusiveArch line that restricts them to only these architectures.
-
-The `+%{nodejs_arches}+` macro is provided to make this easy, so pure JavaScript packages must use:
-
-....
-ExclusiveArch: %{nodejs_arches} noarch
-....
-
-Native (binary) packages must omit `+noarch+` and list only `+%{nodejs_arches}+` or the list of architectures as appropriate.
-
-== Bundled Licenses
-
-The licenses of the bundled Node.js modules need to be in the spec file.
-If you are using our bundling script,
-they will be listed in `+<package>-<version>-bundled-licenses.txt+`.
-It is recommended that you include `+<package>-<version>-bundled-licenses.txt+` in the rpm.
-
-Each time you update your package, you need to verify the bundled licenses against
-https://docs.fedoraproject.org/en-US/legal/allowed-licenses/[Fedoras Software License List].
-Note that precompiled/minimized JavaScript may be packaged,
-but the requirement to verify the licenses also applies to it,
-see the :xref:JavaScript.adoc[JavaScript guidelines].
-
-List all unique licenses on the License: line of your spec file.
-https://docs.fedoraproject.org/en-US/legal/license-field/#_basic_rule[Separate each license with the word "and"].
-
-....
-License:  <license1> AND <license2> AND <license3>
-...
-Source3:        %{npm_name}-%{version}-bundled-licenses.txt
-...
-%prep
-...
-cp %{SOURCE3} .
-...
-%files
-%license LICENSE %{npm_name}-%{version}-bundled-licenses.txt
-....
-
-If you have further questions refer to the https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/[Fedora Licensing Guidelines].
-
-== Using tarballs from the npm registry
-
-The canonical method for shipping most node modules is tarballs from the npm registry. The `+Source0+` for such modules should be of the form https://registry.npmjs.org/[]`+<modulename>/-/<modulename>-<version>.tgz+`. For instance:
-
-....
-Source0:  https://registry.npmjs.org/npm/-/npm-1.1.70.tgz
-....
-
-This method should be preferred to using checkouts from git or automatically generated tarballs from GitHub.
-
-These tarballs store the contents of the module inside a `+package+` directory, so every package using these tarballs should use the following in `+%prep+`:
-
-....
-%prep
-%setup -q -n package
-....
-
-== Using tarballs for bundling
-
-It is prefered to use tarballs for bundling node module dependencies.  These tarballs should be independent from the main package source.  There should be two tarballs. One for the binary, runtime package. One for testing while the package builds.  This creates a smaller installed package.
-
-These tarballs store the bundled modules in a directory called node_modules_prod, and node_modules_dev.
-
-If your packages does not need one of the tarballs, then change these instructions accordingly.  If it does not need the prod tarball, remove  `+Source1+` plus the `+%build+` and `+%install+` sections.  If it does not need the dev tarball, remove  `+Source2+` and the `+%check+` section.
-
-Note1: The setup of the prod and dev tarballs will soon become a macro.  At the time of this writting, they are not.
-
-Note2: The tarball with the dev dependencies needs to be unpacked in +%check+ and not in +%prep+ to avoid accidentally bundling the unpackaged dependencies that are only needed for testing.
-
-....
-...
-Source1:       %{npm_name}-%{version}-nm-prod.tgz
-Source2:       %{npm_name}-%{version}-nm-dev.tgz
-...
-%prep
-...
-# Setup bundled runtime(prod) node modules
-tar xfz %{SOURCE1}
-mkdir -p node_modules
-pushd node_modules
-ln -s ../node_modules_prod/* .
-ln -s ../node_modules_prod/.bin .
-popd
-...
-%install
-...
-# Copy over bundled nodejs modules
-cp -pr node_modules node_modules_prod %{buildroot}%{nodejs_sitelib}/%{npm_name}
-...
-%check
-%{__nodejs} -e 'require("./")'
-# Setup bundled dev node_modules for testing
-#   Note: this cannot be in %%prep or the dev node_modules
-#            can get pulled into the regular rpm
-tar xfz %{SOURCE2}
-pushd node_modules
-ln -s ../node_modules_dev/* .
-popd
-pushd node_modules/.bin
-ln -s ../../node_modules_dev/.bin/* .
-popd
-# Example test run using the binary in ./node_modules/.bin/
-./node_modules/.bin/vows --spec --isolate
-...
-....
-
-== Installing Modules
-
-Most node modules do not contain their own install mechanism. Instead they rely on `+npm+` to do it for them. `+npm+` *must not* be used to install modules in Fedora packages, since it usually requires network access.
-
-Instead, install files in their proper place manually using `+install+` or `+cp+`. Most files should be installed in `+%{nodejs_sitelib}/+` but documentation should be installed via `+%doc+`. In the event that the module ships arch independent content other than JavaScript code, that content should be installed in `+%{_datadir}+` and the module should be patched to cope with that.
-
-=== Client-side JavaScript
-
-Many node modules contain JavaScript that can be used both client-side and server-side and it is sometimes hard to identify code intended only for use in the browser. Since there are no current packaging guidelines for client-side JavaScript and bundling of such code is currently permitted in Fedora, it is currently permissible for client-side JavaScript to be bundled with nodejs modules in `+%{nodejs_sitelib}+`.
-
-== Automatic Requires and Provides
-
-The _nodejs_ package includes an automatic Requires and Provides generator that automatically adds versioned dependencies based on the information provided in a module's and bundled dependencies _package.json_ file. Additional Requires are added to native (binary) modules to protect against ABI breaks in Node or the V8 JavaScript runtime.  Additional Provides: bundled() line is added for e
-
-
-=== Provides npm
-
-It also adds virtual provides in the form `+npm(<module name>)+` to identify modules listed in the npm registry (the module is listed at npmjs.org) . If a module is not listed in the npm registry, it must not provide this. Modules that aren't listed in the npm registry should set `+private+` to `+true+` in their `+package.json+` file. If not, you must patch `+package.json+` to include that.
-
-=== Provides bundled
-
-It also automatically adds bundled provides in the form `+bundled(<bundled_module_name>) = <bundled_module_version>+` to identify bundled modules.  Bundled modules must be in either the _node_modules_ or _node_modules_prod_ directories to be automatically added.
-
-=== Correcting Dependencies
-
-For non-bundled modules only.
-
-Occasionally the dependencies listed in package.json are inaccurate. For instance, the module may work with a newer version of a dependency than the one explictly listed in the _package.json_ file. To correct this, use the `+%nodejs_fixdep+` RPM macro. This macro should be used in `+%prep+` and will patch _package.json_ to contain the correct dependency information.
-
-To convert any dependency to not list a specific version, just call `+%nodejs_fixdep+` with the npm module name of the dependency. This changes the version in _package.json_ to `+*+`. (Or adds one if it wasn't already listed.) For example:
-
-....
-%prep
-%setup -q -n package
-%nodejs_fixdep foomodule
-....
-
-You can also specify a version:
-
-....
-%prep
-%setup -q -n package
-%nodejs_fixdep foomodule '>2.0'
-....
-
-The second argument to `+%nodejs_fixdep+` must be a valid _package.json_ version specifier as explained in https://docs.npmjs.com/files/package.json#version[`+\+`man npm json\`++`].
-
-You can also remove a dependency:
-
-....
-%prep
-%setup -q -n package
-%nodejs_fixdep -r foomodule
-....
-
-== Symlinking Dependencies
-
-For non-bundled modules only.
-
-Node.js and npm require that dependencies explicitly be included or linked into a _node_modules_ directory inside the module directory. To make this easier, a `+%nodejs_symlink_deps+` macro is provided and will automatically create a _node_modules_ tree with symlinks for each dependency listed in _package.json_. This macro should be called in the `+%install+` section of every Node.js module package.
-
-== Building native modules with node-gyp
-
-Most native modules use the `+node-gyp+` tool to build themselves, which configures and uses the `+gyp+` build framework to build addon modules that can interact with Node.js and the V8 JavaScript interpreter used by it.
-
-The WAF build framework has been abandoned by upstream and is not supported in Fedora.
-
-=== BuildRequires
-
-To build a native module designed to be built with node-gyp, add `+BuildRequires: node-gyp+`, along with `+BuildRequires: nodejs-devel+` and _-devel_ packages for any shared libraries needed by the module.
-
-=== %build
-
-Some native modules have Makefiles or other build processes that handle any special needs that module has, such as linking to system versions of dependencies. If present, these should be used. Check the module's _package.json_ file for information about what command npm will run to build these modules.
-
-Most modules use vanilla node-gyp, and may not have build instructions in _package.json_. To build these, simply use the following:
-
-....
-%build
-export CXXFLAGS="%{optflags}"
-node-gyp rebuild
-....
-
-Note that some modules may specify something like `+node-gyp configure && node-gyp build+`. This is equivalent to `+node-gyp rebuild+`.
-
-=== %install
-
-`+node-gyp+` creates a shared object file with the extension `+.node+` as part of its build process, which should be located in `+build/Release+`. This file may be used as the main entry point for the library, or is utilized by JavaScript wrapper code included with the module.
-
-If the shared object is used as the main entry point, it should be installed at `+%{nodejs_sitelib}/<module name>/index.node+`. The `+require()+` function will automatically load this if there is no corresponding `+index.js+` or entry point defined in _package.json_ to override it. For example:
-
-....
-%install
-mkdir -p %{buildroot}%{nodejs_sitelib}/foomodule
-cp -p build/Release/index.node package.json %{buildroot}%{nodejs_sitelib}/foomodule/
-....
-
-If the shared object is called by JavaScript wrapper code, the situation is slightly more complicated.
-
-If the module uses the npm https://npmjs.org/package/bindings[_bindings_] module, the shared object file should be installed in `+%{nodejs_sitelib}/<module name>/build/<module name>.node+`, which is at the top of https://npmjs.org/package/bindings[_bindings_] search path and where `+node-gyp+` usually creates a symlink to wherever the real shared object file exists. For example:
-
-....
-%install
-mkdir -p %{buildroot}%{nodejs_sitelib}/foomodule/build
-cp -p package.json wrapper.js %{buildroot}%{nodejs_sitelib}/foomodule/
-cp -p build/Release/foomodule.node %{buildroot}%{nodejs_sitelib}/foomodule/build/
-....
-
-If the module hardcodes `+build/Release/<module name>.node+`, the module should be patched to use `+build/<module name>.node+` instead, and upstream should be advised that they should use the https://npmjs.org/package/bindings[_bindings_] module, because their module could break when users use debug builds of node.
-
-If the module uses it's own Makefiles to locate the shared object file(s) to a specific location, then those files should installed in that location.
-
-=== Filtering Unwanted Provides
-
-RPM automatically adds some unwanted virtual provides to the shared object files included with native modules. To remove them, add `+%{?nodejs_default_filter}+` to the top of the package's spec file. For more information, see xref:AutoProvidesAndRequiresFiltering.adoc[Packaging:AutoProvidesAndRequiresFiltering].
-
-== Build testing in %check
-
-All Node.js module spec files must include a `+%check+` section that contains (at minimum) the line:
-
-....
-%{__nodejs} -e 'require("./")'
-....
-
-This test ensures that the module is actually loadable, which will help avoid situations where a new upstream release has added a new dependency without the packager noticing.
-
-Any other tests made available by upstream should also be run wherever possible.
-
-For convienence, %nodejs_symlink_deps also accepts a `+--check+` argument, which will make it operate in the current working directory instead of the buildroot. You can use this in the `+%check+` section to make dependencies available for running tests. When this argument is used, development dependencies as listed in the "devDependencies" key in _package.json_ are also linked.
-
-== Bundling Script
-
-It is recommended to use the nodejs-packaging-bundler script found in the Fedora nodejs-packaging-bundler package.  More documentation for it can be found at the  https://src.fedoraproject.org/rpms/nodejs-packaging/[Fedora nodejs-packaging repo] .
-
-== Example Spec
-
-....
-%global npm_name tape
-
-Name:           nodejs-%{npm_name}
-Version:        5.1.1
-Release:        1%{?dist}
-Summary:        Tap-producing test harness for Node.js and browsers
-
-License:        MIT AND ISC
-URL:            https://github.com/substack/tape
-Source0:        https://registry.npmjs.org/%{npm_name}/-/%{npm_name}-%{version}.tgz
-Source1:        %{npm_name}-%{version}-nm-prod.tgz
-Source2:        %{npm_name}-%{version}-nm-dev.tgz
-Source3:        %{npm_name}-%{version}-bundled-licenses.txt
-
-BuildArch:      noarch
-ExclusiveArch:  %{nodejs_arches} noarch
-
-Requires:       nodejs
-BuildRequires:  nodejs-devel
-
-%description
-%{summary}.
-
-
-%prep
-%setup -q -n package
-cp %{SOURCE3} .
-# Setup bundled runtime(prod) node modules
-tar xfz %{SOURCE1}
-mkdir -p node_modules
-pushd node_modules
-ln -s ../node_modules_prod/* .
-ln -s ../node_modules_prod/.bin .
-popd
-
-%build
-#nothing to do
-
-%install
-mkdir -p %{buildroot}%{nodejs_sitelib}/%{npm_name}
-cp -pr package.json index.js lib/ \
-    %{buildroot}%{nodejs_sitelib}/%{npm_name}
-# Copy over bundled nodejs modules
-cp -pr node_modules node_modules_prod \
-    %{buildroot}%{nodejs_sitelib}/%{npm_name}
-
-mkdir -p %{buildroot}%{nodejs_sitelib}/tape/bin
-install -p -D -m0755 bin/tape %{buildroot}%{nodejs_sitelib}/tape/bin/tape
-mkdir -p %{buildroot}%{_bindir}
-ln -sr %{nodejs_sitelib}/tape/bin/tape %{buildroot}%{_bindir}/tape
-
-%check
-%{__nodejs} -e 'require("./")'
-# Setup bundled dev node_modules for testing
-#   Note: this cannot be in %%prep or the dev node_modules
-#            can get pulled into the regular rpm
-tar xfz %{SOURCE2}
-pushd node_modules
-ln -s ../node_modules_dev/* .
-popd
-pushd node_modules/.bin
-ln -s ../../node_modules_dev/.bin/* .
-popd
-# Run tests
-./node_modules/.bin/tap test/*.js
-
-
-%files
-%doc readme.markdown
-%license LICENSE %{npm_name}-%{version}-bundled-licenses.txt
-%{nodejs_sitelib}/tape
-%{_bindir}/tape
-
-
-%changelog
-....
diff --git a/guidelines/modules/ROOT/pages/OCaml.adoc b/guidelines/modules/ROOT/pages/OCaml.adoc
deleted file mode 100644
index b88fe59..0000000
--- a/guidelines/modules/ROOT/pages/OCaml.adoc
+++ /dev/null
@@ -1,219 +0,0 @@
-= OCaml Packaging Guidelines
-
-This document seeks to document the conventions and customs surrounding the proper packaging of OCaml modules in Fedora.
-It does not intend to cover all situations, but to codify those practices which have served the Fedora OCaml community well.
-
-== Naming
-
-The base OCaml compiler is called ocaml.
-
-OCaml modules, libraries and syntax extensions should be named ocaml-foo.
-Examples include: `ocaml-extlib`, `ocaml-ssl`.
-
-This naming does not apply to applications written in OCaml, which can be given their normal name.
-Examples include: `coccinelle`, `frama-c`, `virt-top`.
-
-Rationale: this is how they are named in other distros (Debian, PLD) and this is consistent with Perl / PHP / Python naming.
-
-== Packaging libraries
-
-=== Main package
-
-In order to allow OCaml scripts and the toplevel to use a library, the main package should contain only files matching:
-
-* `*.cma` (contains the bytecode)
-* `*.cmi` (contains the compiled signature)
-* `*.so` (if present, contains OCaml <-> C stubs)
-* `META` (the findlib description)
-* `*.so.owner` (if present, used by findlib)
-* a license file (if present) marked `%license`
-
-* `.cmo` files are not normally included. There is one exception where `*.cmo` files may be included: if the `.cmo` file is needed to link, then it must be included to allow the library to be linked properly.
-
-If the package contains `*.so` files, then they should not have rpaths, as per Fedora packaging guidelines.
-
-The packager should check the `META` file footnote:[http://projects.camlcity.org/projects/dl/findlib-1.9.5/doc/ref-html/r759.html[findlib Reference Manual - META files.]].
-If there is no `META` file, then the packager should create one, include it in the package, and pass it to the upstream maintainer.
-
-Rationale: OCaml does not support dynamic linking of binaries, and even if it did with the current module hash system for expressing strict typing requirements almost any conceivable change to a library would require the binary to be recompiled.
-OCaml scripts are the closest we come to dynamic linking, in as much as they do not usually depend on a specific version of a library (albeit this only works because the scripts are recompiled each time they run).
-
-=== `-devel` subpackage
-
-The `-devel` subpackage of a library should contain all other files required to allow development with the library. Normally these would be:
-
-* `*.a` (contains the compiled machine code)
-* `*.cmxa` (describes the compiled machine code)
-* `*.cmx` (if present, allows cross-module optimizations)
-* `*.mli` (contains the signature of the library)
-* `*.cmt` (contains type annotations for compiled code)
-* `*.cmti` (contains type annotations for interface files)
-
-* `.o` files are not normally included. There is one exception -- if the file is needed to link (like `std_exit.cmx` and `std_exit.o` in OCaml itself), then it should be included.
-
-* `.ml` files are not normally included. The exception is if the file describes a module signature _and_ there is no corresponding `.mli` file, then the `.ml` file should be included. (Note that Debian is more permissive and they often distribute `*.ml` files, allowing the programmer to peek at the implementation of a module).
-
-Documentation, examples and other articles which are useful to the developer may be included in the `-devel` sub-package.
-The license file (which is in the main package) does not need to be included again in the `-devel` subpackage.
-
-If the `-devel` subpackage would only contain documentation files, then the packager may at their discretion place the documentation files in the main package and not have a `-devel` subpackage at all.
-
-The `-devel` subpackage should require the exact name-version-release of the main package (as per Fedora policy).
-It should also require any C libraries required for development, and sometimes this means an explicit `Requires` is needed.
-For example, `ocaml-pcre-devel` needs an explicit `Requires: pcre-devel` to make it usable for development.
-
-Rationale for inclusion of all `.cmx` files: these files are needed even for modules included in `.cmxa` libraries in order to enable cross-module optimizations (inlining, constant propagation and direct function calls).
-The `.o` files are not needed. [From a private email from Alain Frisch]
-
-=== `-doc` subpackage
-
-If the documentation files are very large they may be placed in a separate `-doc` subpackage, as per normal Fedora guidelines.
-
-=== `-data` subpackage
-
-If the package contains excessively large data files, they may be placed in a separate `-data` subpackage, as per normal Fedora guidelines.
-
-=== `Requires` and `Provides`
-
-For each module that library `A` uses from another library `B`, library `A` must have a `Requires` of the form:
-`ocaml(Modulename) = MD5hash`
-
-Similarly for each module that library `A` may provide to other libraries, library `A` must have a `Provides` of the same form.
-
-A library must depend on the precise version of the OCaml compiler, for example:
-`ocaml(runtime) = 3.10.0`
-
-The correct `Requires` and `Provides` should be generated automatically.
-
-Rationale: OCaml does not offer binary compatibility between releases of the compiler (even between bugfixes).
-Furthermore the module system uses a hash over the interface and some internals of a module which basically means a library or program must be linked against the identical modules it was compiled with.
-The `Requires` and `Provides` lines express the module name and hash so that RPM enforces the same requirements as the OCaml linker itself.
-Please see the further reading at the end of this page for more details.
-
-== Packaging binaries
-
-The rules for packaging OCaml binaries are not significantly different from packaging ordinary programs (see xref:index.adoc[Packaging Guidelines]).
-
-However if the OCaml package also contains a library, then you should follow the rules above for packaging libraries as well.
-
-=== Stripping binaries
-
-Binaries should be stripped, as per ordinary Fedora packaging guidelines.
-
-There is one exception where a binary should not be stripped.
-If the package was compiled with `ocamlc -custom` then the package contains bytecode which strip will remove, thus rendering the binary inoperable.
-It is easy to test for this: if after stripping, any attempt to run the binary results in the message `No bytecode file specified` then the binary is compiled like this and should not be stripped.
-
-Rationale: https://bugs.debian.org/256900
-
-=== Providing best possible binaries
-
-The packager should attempt to ship native code compiled binaries in preference to bytecode compiled binaries, where this is possible.
-
-== Bytecode-only architectures
-
-The OCaml native code compiler (`ocamlopt`) contains code generators for popular architectures, but not for every architecture that Fedora might support.
-On such architectures, the spec file should still build bytecode libraries and binaries.
-
-To test for presence of the native compiler, use the `+%{ocaml_native_compiler}+` macro.
-Define conditional sections in %build, %install and %files if necessary.
-For example:
-
-....
-%build
-make byte
-%ifarch %{ocaml_native_compiler}
-make opt
-%endif
-....
-
-To test that your spec file will work on such an architecture, temporarily remove or rename `/usr/bin/ocamlopt` and `/usr/bin/ocamlopt.opt` while building.
-
-Rationale: Debian packaging policy section 2.3 does the same thing.
-
-== Unnecessary files
-
-The following files should not normally be distributed:
-
-* `*.cmo` object files. Exception: see above.
-* `*.o` for corresponding `*.cmx`. Exception: see above.
-* `*.ml` sources. Exception: see above.
-
-== Security issues in OCaml libraries
-
-If a security issue arises in an OCaml library, then all libraries and binaries which depend on it must be recompiled.
-
-OCaml scripts do not need to be changed (unless resolving the security issue requires changing the public interface to the library and the script is broken by the change).
-This is because OCaml scripts are recompiled each time they run.
-
-== RPM Macros
-
-The following macros are available to use in spec files:
-
-* `+%{ocaml_native_compiler}+`: the architectures for which native compilation is available
-* `+%{ocaml_natdynlink}+`: the architectures for which native dynamic linking is available
-* `+%{ocamldir}+`: top-level installation directory for OCaml packages, currently equivalent to `+%{_libdir}/ocaml+`
-* `+%{ocaml_files}+`: generate a list of installed files, in files named `.ofiles` (for the main package) and .ofiles-devel (for the devel subpackage), unless `-s` or `-n` is given.  This macro requires that python3 be available in the buildroot.  Flags:
-** `-n`: there is no devel subpackage.  All files are listed in `.ofiles`.
-** `-s`: separate installation; each subdirectory of `+%{ocamldir}+` is a separate RPM package.  For each subdirectory, `.ofiles-<subdir>` and `.ofiles-<subdir>-devel` is generated (unless `-n` is also given).
-
-== Examples
-
-This section contains example spec files illustrating how to build OCaml library and binary packages with various build tools.
-
-=== Dune
-
-Dune is a popular build tool for OCaml packages.
-RPM macros are available to make building with dune simple.
-
-* `%dune_build`: Invoke dune to build all installable artifacts in release mode.  Flags:
-** `-j <number>`: number of jobs that can be run in parallel.  This is automatically set to `%{?_smp_mflags}`, so is typically used only to eliminate parallelism with `-j 1`.
-** `-p <modules>`: tell dune to build the comma-separated list of modules only, rather than every installable artifact.
-** `--`: separate flags for this macro from flags to pass to dune
-* `%dune_install`: Invoke dune to install all installable artifacts.  Flags:
-** `-n`: there is no devel subpackage.  All files are associated with the main package.
-** `-s`: separate installation; each subdirectory of `+%{ocamldir}+` is a separate RPM package.  Otherwise, all files are associated with a single main package.
-** `--`: separate flags for this macro from flags to pass to dune
-* `%dune_check`: Invoke dune to run tests for all installable artifacts.  Flags:
-** `-j <number>`: number of jobs that can be run in parallel.  This is automatically set to `%{?_smp_mflags}`, so is typically used only to eliminate parallelism with `-j 1`.
-** `-p <modules>`: tell dune to build the comma-separated list of modules only, rather than every installable artifact.
-** `--`: separate flags for this macro from flags to pass to dune
-* `%odoc_package`: Declare a subpackage that olds odoc-generated documentation.  Flags:
-** `-L <license_filename>`: give the name of a file to include in the subpackage as a license file.
-
-The following is an example specfile for an imaginary OCaml library called _foolib_ that is built with `dune`.
-
-.ocaml-dune-example.spec
-[source]
-----
-include::{examplesdir}/ocaml-dune-example.spec[]
-----
-
-=== `Topkg`
-
-`topkg`, the "transitory OCaml software packager", generates scripts that are executed to perform various package and build tasks.
-
-The following is an example specfile for an imaginary OCaml library called _foolib_ that is built with `topkg`.
-
-.ocaml-topkg-example.spec
-[source]
-----
-include::{examplesdir}/ocaml-topkg-example.spec[]
-----
-
-=== Other build tools
-
-The following is an example specfile for an imaginary OCaml library called _foolib_.
-
-.ocaml-example.spec
-[source]
-----
-include::{examplesdir}/ocaml-example.spec[]
-----
-
-== Further reading
-
-* https://lists.debian.org/debian-ocaml-maint/2005/01/threads.html#00042 - Thread on ABI compatibility of different versions of OCaml.
-* https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01234.html - Explains lack of dynamic linking in upstream.
-* https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01280.html - Proposal to include MD5 sums in RPM deps.
-* https://bugzilla.redhat.com/show_bug.cgi?id=433783 - Common rpmlint errors and warnings in OCaml packages.
diff --git a/guidelines/modules/ROOT/pages/Octave.adoc b/guidelines/modules/ROOT/pages/Octave.adoc
deleted file mode 100644
index 1208121..0000000
--- a/guidelines/modules/ROOT/pages/Octave.adoc
+++ /dev/null
@@ -1,210 +0,0 @@
-= Octave Packaging Guidelines
-
-== What is Octave?
-
-The definition from https://www.octave.org/[website] says:
-
-_"GNU Octave is a high-level language, primarily intended for numerical computations. It provides a convenient command line interface for solving linear and nonlinear problems numerically, and for performing other numerical experiments using a language that is mostly compatible with Matlab. It may also be used as a batch-oriented language."_
-
-If you are interested in packaging Octave packages, you should check here for upstream sources:
-
-* https://octave.sourceforge.io/[The Octave Forge website]
-
-== RPM macros
-
-The following macros are defined in /etc/rpm/macros.octave in the octave 3.4.0 (Fedora 15+) package for help in packaging:
-
-....
-# Octave binary API provided
-%octave_api %(octave-config -p API_VERSION || echo 0)}
-
-# Octave Package Directories
-%octshareprefix %{_datadir}/octave
-%octprefix %{octshareprefix}/packages
-%octarchprefix %{_libdir}/octave/packages
-
-%octpkgdir %{octshareprefix}/%{octpkg}-%{version}
-%octpkglibdir %{octarchprefix}/%{octpkg}-%{version}
-
-# Run an octave command - quietly with no startup files
-%octave_cmd()
-
-# Build Source into a package tar file in a temporary location
-%octave_pkg_build
-
-# Install a package.  We use the octave pkg install command to install the
-# built package into the buildroot.  We also put a note to prevent the root
-# user from removing the package with the octave pkg uninstall command
-%octave_pkg_install 
-
-# preun script - we need to remove our uninstall protection and perhaps
-# run the package's own uninstall script.
-%octave_pkg_preun
-....
-
-== Octave packaging tips
-
-=== Naming of Octave packages
-
-Packages of Octave packages have their own naming scheme. They should take into account the upstream name of the package. This makes a package name format of `+octave-$NAME+`. When in doubt, use the name of the module that you type to import it in octave.
-
-'''Examples: '''
-
-....
-octave-java (Octave package named java)
-octave-gsl (Octave package named gsl)
-....
-
-Limitations in the pkg function of octave (pkg.m) means that versioning of octave packages requires that the package version must have a MAJOR.MINOR.MICRO format. Failing to use this format results in octave not recognising binary package components in %prefix/libexec.
-
-=== Updating the octave package database
-
-Octave maintains a list of installed packages in /usr/share/octave/octave_packages that needs to be updated on package install and removal. This file is in an octave plain-text format.
-
-The contents of the /usr/share/octave/packages/ directory are scanned for the following files when performing a pkg('rebuild') from within octave.
-
-* /usr/share/octave/packages/_NAMEOFPACKAGE_/packinfo/COPYING
-* /usr/share/octave/packages/_NAMEOFPACKAGE_/packinfo/DESCRIPTION
-
-If these files are not present in any given _NAMEOFPACKAGE_ directory, then octave will silently skip the folder and fail to index it correctly.
-
-Octave will use the contents of octave_packages to modify its path at startup, allowing octave to find plugins.
-
-=== Documentation files
-
-All package files are installed into the octave directories.
-
-== Spec Templates for Octave packages
-
-There are two types of Octave packages: arch-specific and noarch.
-
-=== Arch specific Octave spec template
-
-....
-%global octpkg image
-# Exclude .oct files from provides
-%global __provides_exclude_from ^%{octpkglibdir}/.*\\.oct$
-
-Name:           octave-%{octpkg}
-Version:        1.0.13
-Release:        1%{?dist}
-Summary:        Image processing for Octave
-Group:          Applications/Engineering
-License:        GPL-2.0-or-later
-URL:            https://octave.sourceforge.io/image/
-Source:         https://downloads.sourceforge.net/octave/%{octpkg}-%{version}.tar.gz
-
-BuildRequires:  octave-devel
-
-Requires:       octave(api) = %{octave_api}
-Requires(post): octave
-Requires(postun): octave
-
-%description
-The Octave-forge Image package provides functions for processing images. The
-package also provides functions for feature extraction, image statistics,
-spatial and geometric transformations, morphological operations, linear
-filtering, and much more. 
-
-
-%prep
-%setup -q -n %{octpkg}-%{version}
-
-
-%build
-%octave_pkg_build
-
-
-%install
-%octave_pkg_install
-
-
-%post
-%octave_cmd pkg rebuild
-
-%preun
-%octave_pkg_preun
-
-%postun
-%octave_cmd pkg rebuild
-
-%files
-%{octpkglibdir}
-%dir %{octpkgdir}
-%{octpkgdir}/*.m
-%doc %{octpkgdir}/doc-cache
-%{octpkgdir}/packinfo
-
-
-%changelog
-* Sat Feb 12 2011 Orion Poplawski <orion@cora.nwra.com> 1.0.13-1
-- Initial Fedora package
-....
-
-=== Noarch Octave spec template
-
-....
-%global octpkg actuarial
-
-Name:           octave-%{octpkg}
-Version:        1.1.0
-Release:        1%{?dist}
-Summary:        Actuarial functions for Octave
-Group:          Applications/Engineering
-License:        GPLv2+
-URL:            https://octave.sourceforge.io
-Source:         https://downloads.sourceforge.net/octave/%{octpkg}-%{version}.tar.gz
-BuildArch:      noarch
-
-BuildRequires:  octave-devel
-
-Requires:       octave
-Requires(post): octave
-Requires(postun): octave
-
-%description
-Actuarial functions for Casualty and Property lines.
-
-
-%prep
-%setup -q -n %{octpkg}-%{version}
-
-
-%build
-%octave_pkg_build
-
-
-%install
-%octave_pkg_install
-
-
-%post
-%octave_cmd pkg rebuild
-
-%preun
-%octave_pkg_preun
-
-%postun
-%octave_cmd pkg rebuild
-
-%files
-%dir %{octpkgdir}
-%{octpkgdir}/*.m
-%doc %{octpkgdir}/doc-cache
-%{octpkgdir}/packinfo
-
-
-%changelog
-* Sat Feb 12 2011 Orion Poplawski <orion@cora.nwra.com> 1.1.0-1
-- Initial Fedora package
-....
-
-=== Summary of differences between arch-specific and noarch octave packages
-
-* Noarch packages set `+BuildArch: noarch+`
-* Don't require a specific API version
-* Noarch packages don't install anything into %\{octpkglibdir}
-
-=== Obsoletes notes
-
-Packages that used to be in the octave-forge package need to have the Obsoletes line above. Packages that were not do not.
diff --git a/guidelines/modules/ROOT/pages/PHP.adoc b/guidelines/modules/ROOT/pages/PHP.adoc
deleted file mode 100644
index 8842f70..0000000
--- a/guidelines/modules/ROOT/pages/PHP.adoc
+++ /dev/null
@@ -1,577 +0,0 @@
-= PHP Packaging Guidelines
-
-Fedora Packaging Guidelines for PHP addon modules
-
-[#types]
-== Different types of PHP packages
-
-There are basically 4 different kinds of PHP modules, which are packaged for Fedora:
-
-* https://pecl.php.net[PECL] (PHP Extension Community Library) modules,
-which are PHP modules usually written in C
-and are dynamically loaded by the PHP interpreter on startup.
-This will be deprecated in favor of PIE.
-
-* https://pear.php.net[PEAR] (PHP Extension and Application Repository) modules,
-which are reusable components written in PHP, usually classes,
-which can be used in your own PHP applications and scripts
-by using e.g. the `+include()+` directive.
-This is deprecated in favor of composer and discouraged.
-
-* Composer registered libraries,
-which are reusable components written in PHP,
-usually PSR-0 compliant classes,
-registered on a package registry,
-most often on https://packagist.org/[Packagist].
-
-* CHANNEL : packages which register a channel.
-A channel is a repository which provides PHP extensions.
-This is deprecated and discouraged.
-
-* https://github.com/php/pie[PIE] registered extensions,
-which are PHP modules usually written in C and are dynamically loaded by
-the PHP interpreter on startup, registered on a package registry,
-most often on https://packagist.org/extensions[Packagist].
-
-
-* Other packages providing a PHP extension not handled by PEAR/PECL mechanisms.
-
-While upstream uses the same package and distribution format for PECL and PEAR,
-creating RPMs has to take some differences into account.
-
-3 channels are defined on installation of `+php-pear+`:
-
-* `+pear.php.net+` (alias `+pear+`) :
-the default channel for PHP Extension and Application Repository
-
-* `+pecl.php.net+` (alias `+pecl+`) :
-the default channel for PHP Extension Community Library
-
-* `+__uri+` :
-Pseudo-channel for static packages
-
-Other channels must be configured at RPM build time
-and at at RPM installation time.
-
-[#naming-scheme]
-== Naming scheme
-
-* PECL packages from standard pecl channel should be named
-`+php-pecl-PECLPackageName-%{version}-%{release}.%{arch}.rpm+`.
-
-* PEAR packages from standard pear channel should be named
-`+php-pear-PEARPackageName-%{version}-%{release}.noarch.rpm+`.
-
-* CHANNEL packages should be named
-`+php-channel-ChannelAlias-%{version}-%{release}.noarch.rpm+`
-
-* Packages from another channel should be named
-`+php-ChannelAlias-PackageName-%{version}-%{release}.noarch.rpm+`
-
-* Composer enabled packages
-(referenced in packagist.org or another registry)
-should be named
-`+php-vendor-library-%{version}-%{release}.noarch.rpm+`
-(where `+vendor/library+` is the known packagist name,
-`+name+` attribute in `+composer.json+`).
-When `+vendor+` equals `+library+`, one can be dropped
-(ex `+symfony/symfony+` can be named `+php-symfony+`).
-
-* PIE enabled packages (referenced in packagist.org or another registry)
-should be named
-`+php-vendor-extension-%{version}-%{release}.%{arch}.rpm+`
-(where `+vendor/extension+` is the known packagist name,
-`+name+` attribute in `+composer.json+`).
-When `+vendor+` equals `+extension+`, one can be dropped
-(ex `+xdebug/xdebug+` can be named `+php-xdebug+`).
-
-
-* Other packages should be named
-`+php-PackageName-%{version}-%{release}.%{arch}.rpm+`;
-`+%{arch}+` can be `+noarch+` where appropriate.
-
-Please make sure that a pure PHP package (PEAR, packagist...)
-is correctly being built for `+noarch+`.
-
-As for other packages,
-name should only use lowercase, underscore and slash replaced by dash.
-
-The `+PECLPackageName+` and the `+PEARPackageName+` should be consistent
-with the upstream naming scheme.
-The Crack PHP Extension would thus be named `+php-pecl-crack+`
-with the resulting packages being
-`+php-pecl-crack-0.4-1.i386.rpm+` and `+php-pecl-crack-0.4-1.src.rpm+`.
-
-Note that applications that happen to be written in PHP
-do not belong under the `+php-*+` namespace.
-
-[#file-placement]
-== File Placement
-
-Non-PEAR PHP software which provides shared libraries
-should put its PHP source files for such shared libraries
-in a subfolder of `+%{_datadir}/php+`,
-named according to the name of the software.
-For example, a library called _Whizz_Bang_
-(with a RPM called `+php-something-Whizz-Bang+`)
-would put the PHP source files for its shared libraries
-in `+%{_datadir}/php/Whizz_Bang+`.
-
-A PSR-0 footnote:[https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md[PSR-0]] compliant library
-would put its PHP files in `+%{_datadir}/php/+`
-
-A PSR-4 footnote:[https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader.md[PSR-4]] compliant library
-would put its PHP files in `+%{_datadir}/php/+`
-in a PSR-0 compliant tree.
-
-PEAR documentation provided by upstream are installed in `+%{pear_docdir}+`,
-should stay there,
-and must be marked as `+%doc+`.
-
-PECL documentation provided by upstream is installed in `+%{pecl_docdir}+`,
-should stay there,
-and must be marked as `+%doc+`.
-
-The `+composer.json+` file is not used,
-and should be installed as `+%doc+`
-as it provides useful information about the package and its dependencies.
-
-[#requires-provides]
-== Requires and Provides
-
-[#requires-provides-pear]
-=== PEAR Packages from the standard channel/repository
-
-A PEAR package *MUST* have:
-
-....
-BuildRequires:    php-pear(PEAR)
-Requires:         php-pear(PEAR)
-Requires(post):   %{__pear}
-Requires(postun): %{__pear}
-Provides:         php-pear(foo) = %{version}
-....
-
-The virtual provide should match exactly upstream name,
-including case and underscore, ex: `+php-pear(Text_Wiki)+`
-
-A PEAR package must have all its dependencies available as PEAR packages,
-so should only requires those using the `+php-pear(foo)+` virtual provides.
-Known exception for unbundled libraries
-(which are often bundled because not available in any PEAR channel).
-
-[#requires-provides-channel]
-=== Packages for CHANNEL (repository) configuration
-
-A CHANNEL package *MUST* have :
-
-....
-Requires:         php-pear(PEAR)
-Requires(post):   %{__pear}
-Requires(postun): %{__pear}
-Provides:         php-channel(channelname)
-....
-
-[#requires-provides-pear-nonstandard]
-=== PEAR Packages from a non standard channel/repository
-
-A PEAR package *MUST* have:
-
-....
-BuildRequires:    php-channel(channelname)
-BuildRequires:    php-pear(PEAR)
-Requires:         php-pear(PEAR)
-Requires(post):   %{__pear}
-Requires(postun): %{__pear}
-Requires:         php-channel(channelname)
-Provides:         php-pear(channelname/foo) = %{version}
-....
-
-[#requires-provides-composer]
-=== Composer registered Packages
-
-Each package registered on https://packagist.org/[Packagist]
-(which is the most widely used registry,
-so defined as the implicit one)
-*MUST* have
-
-....
-Provides:     php-composer(vendor/library) = %{version}
-....
-
-Package registered on another registry *MUST* have
-
-....
-Provides:     php-composer(registry_url/vendor/library) = %{version}
-....
-
-The virtual provide should match exactly upstream name,
-including underscore,
-ex: `+php-composer(pear/console_table)+`
-
-Packages moved from PEAR to Composer/Packagist
-should also Provide `+php-pear(foo)+`
-when needed (used by other PEAR packages).
-
-Packages must not Require any `+php-pear(foo)+`,
-but should use `+php-composer(pear/foo)+`.
-
-`+composer.json+` useful attributes
-(see https://getcomposer.org/doc/04-schema.md[Composer schema documentation])
-
-* `+name+`
-
-* `+description+` : 1 line, could be used as RPM summary attribute
-
-* `+homepage+` : could be used as RPM URL attribute
-
-* `+license+`
-
-* `+require+` :
-describes mandatory dependencies
-PHP version,
-PHP extensions
-or other composer libraries,
-those must be required by the RPM package as `+php-composer(foo)+`
-
-* `+require-dev+` :
-describes development dependencies,
-usually useful a build time (ex: to run unit test),
-so could appear as BuidRequires
-
-* `+suggest+` :
-describes optional dependencies,
-so could appear as Requires (packager choice)
-
-* `+conflict+` : as RPM Conflicts
-
-* `+replace+` : as RPM Obsoletes
-
-* `+provide+` :
-for additional virtual provides,
-must also be in RPM Provides as `+php-composer(foo)+`
-
-[#requires-provides-c]
-=== C extensions (PECL and others)
-
-To be certain that a binary extension will run correctly
-with a particular version of PHP,
-it is necessary to check that a particular package
-has both API and ABIs matching the installed version of PHP.
-The mechanism for doing this is as follows:
-
-....
-BuildRequires: php-devel
-Requires:      php(zend-abi) = %{php_zend_api}
-Requires:      php(api) = %{php_core_api}
-....
-
-Each extension *MUST* also have (to track the move out/in of php-src),
-using the `+module+` name as reported by "php --modules"
-or the .so file name in lowercase.
-
-....
-Provides:     php-module = %{version}
-Provides:     php-module%{_isa} = %{version}
-....
-
-
-[#requires-provides-pecl]
-=== PECL Packages
-
-PECL extension *MUST* have ABI check
-(see xref:requires-provides-c[C extensions] above).
-
-A PECL package *MUST* also have:
-
-....
-Provides:     php-pecl(foo) = %{version}
-Provides:     php-pecl(foo)%{?_isa}  = %{version}
-....
-
-[#requires-provides-pecl-nonstandard]
-=== PECL Packages from a non standard channel/repository
-
-A PECL package from a non standard channel MUST have
-(instead of previous provides)
-
-....
-Requires: php-channel(channelname)
-Provides: php-pecl(channelname/foo) = %{version}
-Provides: php-pecl(channelname/foo)%{?_isa} = %{version}
-....
-
-[#requires-provides-pie]
-=== PIE Packages
-
-PIE extension *MUST* have ABI check
-(see xref:requires-provides-c[C extensions] above).
-
-Each package registered on Packagist
-(which is the most widely used registry, so defined as the implicit one)
-*MUST* have:
-
-....
-Provides:     php-pie(vendor/extension) = %{version}
-....
-
-[#requires-provides-other]
-=== Other Packages
-
-PHP addons which are neither PEAR nor PECL
-should require what makes sense
-(either a base PHP version or a `+php-api+`, `+php(zend-abi)+` as necessary).
-
-[#requires-provides-httpd]
-=== Apache requirement
-
-A PHP library must not have an explicit Requires on `+php+` or `+httpd+`,
-since these libraries could be used with any webserver
-or any SAPI (`+php-cli+`, `+php-cgi+`, `+php-fpm+`, ...).
-
-Only a PHP web application,
-which provides a specific Apache httpd configuration,
-should have a Requires on `+httpd+` and `+mod_php+`.
-
-[#requires-provides-extensions]
-=== Extensions Requires
-
-PHP extensions must have a Requires on all of the dependent extensions
-(`+php-json+`, `+php-gd+`, `+php-mbstring+`, ...).
-These extensions are virtual Provides of the php sub-packages.
-
-Can be ignored as always present:
-`+core+`, `+date+`, `+filter+`, `+hash+`, `+pcre+`, `+random+`,
-`+reflection+`, `+session+`, `+spl+`, `+standard+`.
-
-[#requires-provides-min-php]
-=== Requiring a Minimum PHP version
-
-If you need to specify a minimum PHP version,
-the recommended method is to add a Requires: `+php(language) >= $VERSION+`
-(where `+$VERSION+` is the minimum PHP version).
-
-[#c-pecl-config-file]
-== C extension and PECL package configuration files
-
-Each extension should drop a configuration file
-in `+%{php_inidir}+` and/or `+%{php_ztsinidir}+`
-to enable the extension.
-This file must contain the name of the loaded extension.
-The file must use a numeric prefix to ensure correct load order:
-
-* range 00-19 is reserved for zend_extensions
-(ex: `+10-opcache.ini+`, `+15-xdebug.ini+`, ...)
-
-* range 20-39 is reserved for extensions from php sources
-(ex: `+20-pdo.ini+`, `+30-pdo_pgsql.ini+`, ...)
-
-* range 40-99 is available for other extensions
-(ex: `+40-zip.ini+`, ...)
-
-[#macros-scriptlets]
-== Macros and scriptlets
-
-[#macros-scriptlets-zts]
-=== PHP ZTS extension
-
-When the Apache HTTPD is run in worker mode (instead of prefork mode),
-the ZTS (Zend Thread Safe) version of PHP is used.
-
-If an extension maintainer wants to provide a ZTS version of this extension,
-the maintainer must ensure that:
-
-* the extension is thread safe
-* the libraries used by the extension are thread safe
-
-The `+php-devel+` package provides the necessary files
-to build ZTS modules
-and provides several helper macros:
-
-For standard (NTS) extensions
-
-....
-%{__php}          %{_bindir}/php
-%{php_extdir}     %{_libdir}/php/modules
-%{php_inidir}     %{_sysconfdir}/php.d
-%{php_incldir     %{_includedir}/php
-....
-
-For ZTS extensions
-
-....
-%{__ztsphp}       %{_bindir}/zts-php
-%{php_ztsextdir}  %{_libdir}/php-zts/modules
-%{php_ztsinidir}  %{_sysconfdir}/php-zts.d
-%{php_ztsincldir  %{_includedir}/php-zts/php
-....
-
-`+php-devel+` provides the executables needed during the build of a ZTS extension,
-which are:
-
-* `+zts-phpize+`
-* `+zts-php-config+`
-* `+zts-php+` (which is only useful to run the test suite during build)
-
-[#macros-scriptlets-channel]
-=== Packages for CHANNEL (repository) configuration
-
-Here are some recommended scriptlets
-for properly registering and unregistering the channel:
-
-....
-%post
-if [ $1 -eq  1 ] ; then
-   %{__pear} channel-add %{pear_xmldir}/%{name}.xml > /dev/null || :
-else
-   %{__pear} channel-update %{pear_xmldir}/%{name}.xml > /dev/null ||:
-fi
-
-%postun
-if [ $1 -eq 0 ] ; then
-   %{__pear} channel-delete %{channelname} > /dev/null || :
-fi
-....
-
-[#macros-scriptlets-pear]
-=== PEAR Modules
-
-The `+php-pear+` package provides several useful macros:
-
-* `+%{pear_phpdir}+`
-* `+%{pear_docdir}+` (This evaluates to `+%{_docdir}/pear+`.)
-* `+%{pear_testdir}+`
-* `+%{pear_datadir}+`
-* `+%{pear_xmldir}+`
-* `+%{pear_metadir}+` (This evaluates to `+/var/lib/pear+`.)
-
-These definitions for the .spec should be of interest:
-
-....
-BuildRequires:    php-pear >= 1:1.4.9-1.2
-Provides:         php-pear(PackageName) = %{version}
-Requires:         php-common >= 4.3, php-pear(PEAR)
-Requires(post):   %{_bindir}/pear
-Requires(postun): %{_bindir}/pear
-....
-
-Be sure you delete any PEAR metadata files at the end of `+%install+`:
-
-....
-rm -rf %{buildroot}/%{pear_metadir}/.??* 
-....
-
-Here are some recommended scriptlets for properly registering the module:
-
-....
-%post
-%{_bindir}/pear install --nodeps --soft --force --register-only %{pear_xmldir}/%{name}.xml >/dev/null ||:
-....
-
-And here are some recommended scriptlets for properly unregistering the module,
-from the standard channel:
-
-....
-%postun
-if [ "$1" -eq "0" ] ; then
-%{_bindir}/pear uninstall --nodeps --ignore-errors --register-only Foo_Bar >/dev/null ||:
-fi
-....
-
-From a non standard channel (`+pear+` command requires the channel):
-
-....
-%postun
-if [ "$1" -eq "0" ] ; then
-%{_bindir}/pear uninstall --nodeps --ignore-errors --register-only Foo_channel/Foo_Bar >/dev/null ||:
-fi
-....
-
-[#macros-scriptlets-pecl]
-=== PECL Modules
-
-The `+php-pear+` package provides several useful macros:
-
-* `+%{pecl_phpdir}+`
-* `+%{pecl_docdir}+`
-* `+%{pecl_testdir}+`
-* `+%{pecl_datadir}+`
-* `+%{pecl_xmldir}+`
-
-You may need to define a few additional macros
-to extract some information from PHP.
-It is recommended that you use the following:
-
-....
-%global php_apiver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
-%{!?__pecl:     %{expand: %%global __pecl     %{_bindir}/pecl}}
-%{!?php_extdir: %{expand: %%global php_extdir %(php-config --extension-dir)}}
-....
-
-Module (un)registration is handled automatically
-by file triggers in the `+php-pear+` package.
-
-For older releases,
-here are some recommended scriptlets
-for properly registering and unregistering a module:
-
-....
-BuildRequires: php-pear
-Requires(post): %{__pecl}
-Requires(postun): %{__pecl}
-
-%post
-%{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || :
-
-
-%postun
-if [ $1 -eq 0 ]  ; then
-%{pecl_uninstall} %{pecl_name} >/dev/null || :
-fi
-....
-
-[#macros-scriptlets-other]
-=== Other Modules
-
-If your module includes compiled code,
-you may need to define some macros
-to extract some information from PHP.
-It is recommended that you user the following:
-
-....
-%global php_apiver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
-%global php_extdir  %(php-config --extension-dir 2>/dev/null || echo "undefined")
-%global php_version %(php-config --version 2>/dev/null || echo 0)
-....
-
-[#hints]
-== Additional Hints for Packagers
-
-[#hints-pear-pecl]
-=== PEAR & PECL Packages
-
-The source archive contains a `+package.xml+` outside any directory,
-so you have to use use
-
-....
-%setup -q -c
-....
-
-in your `+%prep+` section to avoid writing files to the build root.
-
-[#hints-pear]
-=== PEAR Packages
-
-To create your initial specfile,
-you can use the default template provided by the `+rpmdevtools+` package:
-
-....
-rpmdev-newspec -t php-pear php-pear-Foo
-....
-
-Or you can generate one;
-make sure you have the `+php-pear-PEAR-Command-Packaging+` package installed:
-
-....
-pear make-rpm-spec Foo.tgz
-....
diff --git a/guidelines/modules/ROOT/pages/PatchUpstreamStatus.adoc b/guidelines/modules/ROOT/pages/PatchUpstreamStatus.adoc
deleted file mode 100644
index 6c5efdc..0000000
--- a/guidelines/modules/ROOT/pages/PatchUpstreamStatus.adoc
+++ /dev/null
@@ -1,47 +0,0 @@
-= Patch status
-
-== All patches should have an upstream bug link or comment
-
-All patches in Fedora spec files *SHOULD* have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, 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 (see https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/[Staying Close to Upstream Projects]). It will help others (and even you) down the line in package maintenance by knowing what patches are likely to appear in a new upstream release.
-
-=== If upstream doesn't have a bug tracker
-
-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
-....
-
-== Why upstream?
-
-Refer https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/[Staying Close to Upstream Projects]
diff --git a/guidelines/modules/ROOT/pages/Per-Product_Configuration.adoc b/guidelines/modules/ROOT/pages/Per-Product_Configuration.adoc
deleted file mode 100644
index 1be3b02..0000000
--- a/guidelines/modules/ROOT/pages/Per-Product_Configuration.adoc
+++ /dev/null
@@ -1,179 +0,0 @@
-= Per-product Configuration Packaging
-
-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.
-
-We want to ensure that all packages have sensible defaults
-for whichever Product on which they are installed,
-while also avoiding situations where users would have some packages installed
-with one Product's defaults and some packages with another.
-
-== Requirements
-
-* All packages MUST have a global default configuration.
-  This configuration will be used
-  whenever a Product-specific default configuration is not required.
-  (For example, if a non-Product install is in use
-  or only Fedora Cloud has a custom configuration
-  and Fedora Workstation was installed).
-* Any package that requires a per-product default configuration
-  MUST provide all alternate configuration files in the same package.
-* Any package that requires a configuration that differs between Products
-  MUST obtain permission from that Product's Working Group before packaging it.
-
-== Global Default Configuration
-
-* The global default configuration
-  MUST be provided by the package that requires it.
-* The global default configuration
-  MUST be named based on the package's normal naming scheme,
-  with the main part of the name being suffixed by -default.
-  For example, if the package normally uses `+foo.conf+`,
-  then the global default configuration
-  MUST be named `+foo-default.conf+`.
-
-== Per-Product Default Configuration
-
-* For each Product requiring a unique default configuration,
-  the packager MUST provide a copy of the default configuration file,
-  modified as appropriate for the specific product.
-* The product-specific configuration file
-  MUST be named based on the package's normal naming scheme,
-  with the main part of the name being suffixed by a dash
-  followed by the name of the product.
-  For example, if the package normally uses `+foo.conf+`,
-  then the Server version MUST be named `+foo-server.conf+`.
-* If the configuration will be symlinked in place,
-  the product-specific configuration file
-  MUST be located in an appropriate part of the `+/etc+` hierarchy.
-  The divergent config file
-  MUST be specified as `+%config(noreplace)+` in `+%files+`
-  as per the usual `+/etc+` packaging guidelines.
-* If the configuration will be copied in place,
-  the product-specific configuration file
-  MUST be located in an appropriate part of the `+/usr/share+` hierarchy.
-  The divergent config file
-  MUST be specified as a normal file in the `+%files+` section.
-
-== Applying Configuration
-
-In order to apply the configuration,
-the packager MUST implement a mechanism
-in the `+%posttrans+` section of the specfile that behaves as follows:
-
-* It MUST first check whether the final config file already exists.
-  If so, the script MUST make no changes.
-+
-[source, rpm-spec]
-----
-%posttrans
-if [ ! -e %{_sysconfdir}/foo/foo.conf ]; then
-    ...
-fi
-----
-
-* Then it MUST use the value of the Fedora `+VARIANT_ID+`
-  to symlink or copy one of the divergent config files
-  (or the default) to the final config file location.
-  It will get this value
-  by importing the contents of `+/etc/os-release+` as shell values.
-  Known values of this field at the time of this writing are
-  "atomichost", "cloud", "server" and "workstation".
-  For more detail, see
-  https://www.freedesktop.org/software/systemd/man/os-release.html#VARIANT_ID=[the os-release(5) man page].
-+
-[source, rpm-spec]
-----
-. /etc/os-release || :
-case "$VARIANT_ID" in
-    server)
-        ln -sf foo-server.conf %{_sysconfdir}/foo/foo.conf || :
-        ;;
-    *)
-        ln -sf foo-default.conf %{_sysconfdir}/foo/foo.conf || :
-        ;;
-    esac
-----
-
-* Lastly, the final config file location
-  MUST be listed in the `+%files+` section with `+%ghost+`:
-+
-[source, rpm-spec]
-----
-%ghost %config(noreplace) %{_sysconfdir}/foo/foo.conf
-----
-
-* For tracking purposes,
-  the package providing the various configuration files
-  MUST also contain a virtual `+Provides:+`
-  for each variant configuration that may be applied:
-+
-[source, rpm-spec]
-----
-Provides: variant_config(Atomic.host)
-Provides: variant_config(Cloud)
-Provides: variant_config(Server)
-Provides: variant_config(Workstation)
-----
-
-== Example (firewalld)
-
-We will assume for the sake of demonstration
-that firewalld will need a custom configuration
-for Fedora Server and Fedora Workstation,
-but that Fedora Cloud will not require any changes from the global default.
-
-[source, rpm-spec]
-----
-...
-Provides: variant_config(Server)
-Provides: variant_config(Workstation)
-...
-
-%posttrans
-# If we don't yet have a symlink or existing file for firewalld.conf,
-# create it. Note: this will intentionally reset the policykit policy
-# at the same time, so they are in sync.
-if [ ! -e %{_sysconfdir}/firewalld/firewalld.conf ]; then
-    # Import /etc/os-release to get the variant definition
-    . /etc/os-release || :
-
-    case "$VARIANT_ID" in
-        server)
-            ln -sf firewalld-server.conf %{_sysconfdir}/firewalld/firewalld.conf || :
-            ln -sf org.fedoraproject.FirewallD1.server.policy \
-                %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.policy || :
-            ;;
-        workstation)
-            ln -sf firewalld-workstation.conf %{_sysconfdir}/firewalld/firewalld.conf || :
-            ln -sf org.fedoraproject.FirewallD1.desktop.policy \
-                %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.policy || :
-            ;;
-        *)
-            ln -sf firewalld-default.conf %{_sysconfdir}/firewalld/firewalld.conf || :
-            # The default firewall policy will be the same as Server
-            ln -sf org.fedoraproject.FirewallD1.server.policy \
-                %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.policy || :
-            ;;
-        esac
-fi
-
-...
-
-%files -f %{name}.lang
-...
-%attr(0750,root,root) %dir %{_sysconfdir}/firewalld
-%ghost %config(noreplace) %{_sysconfdir}/firewalld/firewalld.conf
-%config(noreplace) %{_sysconfdir}/firewalld/firewalld-default.conf
-%config(noreplace) %{_sysconfdir}/firewalld/firewalld-server.conf
-%config(noreplace) %{_sysconfdir}/firewalld/firewalld-workstation.conf
-...
-%ghost %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.policy
-%{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.desktop.policy
-%{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.server.policy
-----
diff --git a/guidelines/modules/ROOT/pages/Perl.adoc b/guidelines/modules/ROOT/pages/Perl.adoc
deleted file mode 100644
index 831a54d..0000000
--- a/guidelines/modules/ROOT/pages/Perl.adoc
+++ /dev/null
@@ -1,172 +0,0 @@
-= Perl Packaging Guidelines
-
-== Module package naming
-
-See xref:Naming.adoc#_perl_modules[Packaging Guidelines: Naming: Perl modules].
-
-== License tag
-
-See https://docs.fedoraproject.org/en-US/legal/license-field/#_perl_packages[Licensing guidelines specific to Perl].
-
-== Directory Ownership
-
-As specified in the xref:index.adoc#_file_and_directory_ownership[general Packaging Guidelines], Perl packages are expected to share ownership of certain directories.
-
-In general, a noarch Perl package must own:
-
-....
-# For noarch packages: vendorlib
-%{perl_vendorlib}/*
-....
-
-...and a arch-specific Perl package must own:
-
-....
-# For arch-specific packages: vendorarch
-%{perl_vendorarch}/*
-%exclude %dir %{perl_vendorarch}/auto/
-....
-
-== Build Dependencies
-
-As stated in xref:index.adoc#buildrequires[Packaging Guidelines: Build-Time Dependencies (BuildRequires)], a package must explicitly indicate its build dependencies (using `+BuildRequires:+`) outside of the minimal set required for RPM to build packages. This includes any dependency on Perl. While Perl may have been in the default buildroot at one time, this is not currently the case.
-
-Below is a list of Perl-related build dependencies you may need.
-
-* `+perl-generators+` – Automatically generates run-time Requires and Provides for installed Perl files. Whenever you install a Perl script or a Perl module, you must include a build dependency on this package.
-
-* `+perl-interpreter+` – The Perl interpreter must be listed as a build dependency if it is called in any way, either explicitly via `+perl+` or `+%__perl+`, or as part of your package's build system.
-
-* `+perl-devel+` - Provides Perl header files. If building architecture-specific code which links to `+libperl.so+` library (e.g. an XS Perl module), you must include `+BuildRequires: perl-devel+`.
-
-If a specific Perl module is required at build time, use `perl(__MODULE__)` syntax as documented above. This applies to so called _core_ modules as well, since they may move in and out of the base Perl package over time.
-
-If you need to limit your package to a specific Perl version, use `+perl(:VERSION)+` dependency with desired version constraint (e.g. `+perl(:VERSION) >= 5.22+`). Do not use a comparison against the version of the `+perl+` package because it includes an epoch number, which makes version comparisons tricky.
-
-== Perl Requires and Provides
-
-Perl packages use the virtual `+perl(Foo)+` naming to indicate a given Perl module. Packages should use this methodology, and not require the package name directly. For example, a package requiring the Perl module Readonly should not explicitly require `+perl-Readonly+`, but rather `+perl(Readonly)+`, which the `+perl-Readonly+` package provides.
-
-It is recommended to include explicit dependencies for core modules, because they can move between sub-packages or disappear from core Perl.
-
-=== Versioned MODULE_COMPAT_ Requires or `+perl-libs+`
-
-Packages with Perl modules installed in %\{perl_vendorarch}, %\{perl_vendorlib}, %\{perl_privlib} or %\{perl_archlib} will automatically gain dependency on `+perl-libs+` for pure Perl modules or a dependency on `+perl(:MODULE_COMPAT_<perl_version>)+` for libraries with compiled code. The dependency is handled by `+perl-generators+`.
-
-Packages that require the Perl interpreter or `+libperl.so+` but do not install modules to the aforementioned directories or explicitly link to `+libperl.so.<perl_version>+` need to handle the dependency manually.
-
-=== Filtering Requires and Provides
-
-RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overridden so that the additional dependencies can be filtered out. Please see xref:AutoProvidesAndRequiresFiltering.adoc#_perl[Packaging Guidelines: Automatic Filtering of Provides and Requires - Perl] for information.
-
-=== Manual Requires and Provides
-
-Under some circumstances, RPM's automatic dependency generator can miss dependencies that should be added.
-This is usually as a result of using language constructs that the dependency script wasn't expecting.
-An example of this is in the `+perl-Class-Accessor-Chained+` package, where the following can be found:
-
-....
-use base 'Class::Accessor::Fast';
-...
-use base 'Class::Accessor';
-....
-
-A tell-tale sign of this particular construct is that the package contains a dependency on `+perl(base)+`, but this is not the only situation in which dependencies can be missed. This package needed additional dependencies as follows:
-
-....
-Requires: perl(Class::Accessor), perl(Class::Accessor::Fast)
-....
-
-In general, it's a good idea to look at the upstream package's documentation for details of other dependencies.
-
-Another similar example of missing requirements can be seen in `+perl-Spreadsheet-WriteExcel+`:
-
-....
-package Spreadsheet::WriteExcel::Utility;
-...
-use autouse 'Date::Calc'  => qw(Delta_DHMS Decode_Date_EU Decode_Date_US);
-use autouse 'Date::Manip' => qw(ParseDate Date_Init);
-....
-
-Similarly, it possible to miss Provides:, as was the case in https://bugzilla.redhat.com/167797[Bug #167797] , where the `+perl-DBD-Pg+` package failed to Provide: `+perl(DBD::Pg)+` due to the following construct in `+DBD::Pg+` version 1.43:
-
-....
-{ package DBD::Pg;
-....
-
-The usual way of writing this, and what's expected by RPM, is:
-
-....
-{
-package DBD::Pg;
-....
-
-So it's wise to examine the Provides: of your packages to check that they are sane and complete.
-If something is missing, it can be fixed either by using manual Provides: entries, or by patching the source to use a format that RPM can parse correctly.
-
-== URL tag
-
-For CPAN-based packages the URL tag should use a non-versioned metacpan.org URL. E.g., if one were packaging the module `+Net::XMPP+`, the URL would be:
-
-....
-URL: https://metacpan.org/release/Net-XMPP
-....
-
-== Testing and Test Suites
-
-Perl packages typically have a large, healthy test suite. It is policy to run as much of the test suite as possible, subject to the technical limitations of the build system. This means, at the least:
-
-* All modules required for tests should be listed as a BuildRequires
-* Any "optional" tests should be enabled
-* Any modules needed for the tests but not yet in Fedora that could be included in Fedora should also be submitted for review
-
-=== When to *not* test
-
-There are a couple caveats here:
-
-* Optional tests do not need to be enabled if they will cause circular build deps
-* Tests which require network or display access should be disabled for the build system, but with a method provided for local builds
-* Tests which do not test package functionality should still be invoked, but their exclusion not be considered a blocker (e.g. `+Test::Pod::Coverage+`, `+Test::Kwalitee+` and the like)
-* Author, "release candidate", or smoke tests do not need to be enabled e.g. tests using `+Perl::Critic+`.
-
-Additionally, for "meta" packages that provide a common interface to a number of similar modules, it is not necessary to package all of the modules that the package supports so long as at least one module exists to allow the meta package to provide functionality. For instance, the package `+perl-JSON-Any+` (`+JSON::Any+`) provides a common interface to `+JSON+`, `+JSON::XS+`, `+JSON::PC+`, `+JSON::Syck+` and `+JSON::DWIM+`; `+JSON::PC+` and `+JSON::DWIM+` are not currently in Fedora and do not need to be packaged as, e.g. `+JSON::XS+` enables `+JSON::Any+`.
-
-== Conditionally enabling/disabling tests
-
-One common way to disable a test for mock but enable it locally is to use a `+_with_foo+` macro test, e.g.,
-
-....
-%check
-%{!?_with_network_tests: rm t/roster.t }
-./Build test
-....
-
-With this construct, an offending test will be removed and not executed, unless `+--with network_tests+` is passed to `+rpmbuild+` or %_with_network_tests is defined somewhere, e.g. in a user's `+$HOME/.rpmmacros+`. This approach preserves the test suite for local builds while working within the technical limitations of the build system.
-
-== Makefile.PL vs Build.PL
-
-Perl modules typically utilize one of two different build systems:
-
-* `+ExtUtils::MakeMaker+`
-* `+Module::Build+`
-
-The two different styles are easily recognizable: `+ExtUtils::MakeMaker+` employs the `+Makefile.PL+` build file, and is the "classical" approach; `+Module::Build+` is a newer approach, with support for things MakeMaker cannot do. While the ultimate choice of which system to employ is clearly in the hands of upstream, if `+Build.PL+` is present in a distribution the packager should employ that build framework unless there is a good reason to do otherwise.
-
-See also PackagingTips/Perl#Makefile.PL_vs_Build.PL .
-
-== .h files in module packages
-
-It is not uncommon for binary module packages to include .h files, see e.g. `+perl-DBI+`, `+perl-Glib+`, `+perl-Gtk2+`. For a variety of reasons these should not be split off into a -devel package.
-
-== Updates of packages
-
-Summary of tools used for updates and helpful comments can be found here Perl/updates.
-
-== Useful tips
-
-Some modules try to pull in modules from CPAN. Instead of patching makefile, you can easily add
-PERL5_CPANPLUS_IS_RUNNING=1 to avoid CPAN entirely.
-
-== Perl SIG
-
-People around Perl, who are packaging, maintaining & reviewing packages. If you are interested in Perl, join https://lists.fedoraproject.org/admin/lists/perl-devel.lists.fedoraproject.org/[the mailing list], where are discussed latest issues.
diff --git a/guidelines/modules/ROOT/pages/Pkcs11Support.adoc b/guidelines/modules/ROOT/pages/Pkcs11Support.adoc
deleted file mode 100644
index a7022ae..0000000
--- a/guidelines/modules/ROOT/pages/Pkcs11Support.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-= PKCS#11 / Smart-Card Support Guidelines
-
-These guidelines are relevant to maintainers of packages with smart cards drivers (PKCS#11 modules), or smart card related tooling. Its purpose is to bring a consistency in smart card handling on the OS; for background and motivation see the https://fedoraproject.org/wiki/User:Nmav/Pkcs11Status[current status of PKCS#11 in Fedora].
-
-== Registering the modules system-wide
-
-Any package in Fedora containing a PKCS#11 provider module, intended to be used outside this package, MUST be registered with https://p11-glue.github.io/p11-glue/[p11-kit]. For example, the https://github.com/OpenSC/OpenSC/wiki[OpenSC] module which supports most major hardware smart cards, will automatically drop a config file into the appropriate place and then its module will automatically appear in well-behaved software which is integrated with the platform and uses p11-kit properly. The appropriate place in Fedora can be obtained with `+pkg-config p11-kit-1 --variable p11_module_configs+` or `+%{_datadir}/p11-kit/modules/+`. The dropped file should have the `.module` suffix and should contain something similar to the contents below (which is the opensc example).
-
- # This file describes how to load the opensc module
- # See: https://p11-glue.freedesktop.org/doc/p11-kit/config.html
-
- # This is a relative path, which means it will be loaded from
- # the p11-kit default path which is usually $(libdir)/pkcs11.
- # Doing it this way allows for packagers to package opensc for
- # 32-bit and 64-bit and make them parallel installable
- module: opensc-pkcs11.so
-
-The provider module, as mentioned in the example below should be installed at `+%{_libdir}/pkcs11/+`.
-
-Once a module is registered the tokens/HSMs provided by it should be listed in the `p11tool` output using the following command:
-
-
- $ p11tool --list-tokens
- 
-The packages SHOULD NOT provide the package config `*.pc` files for the PKCS#11 modules, since the applications are not supposed to link directly against these libraries. The PKCS#11 module shared object SHOULD NOT be in the -devel subpackage either.
-
-[#registered]
-== How applications take advantage of registered provider modules
-
-Packages which can potentially use PKCS#11 tokens SHOULD automatically use the tokens which are present in the system's p11-kit configuration, rather than needing to have a PKCS#11 provider explicitly specified. That can be done by applications using the p11-kit library to get the list of modules, or by applications defaulting to the p11-kit proxy module (`+%{_libdir}/p11-kit-proxy.so+`), if no PKCS#11 provider module was specified by the user. The proxy module, is a single module wrapping all available registered modules.
-
-[#specify-card]
-== How to specify a specific smart card/HSM
-
-https://tools.ietf.org/html/rfc7512[RFC7512] defines a 'PKCS#11 URI' as a standard way to identify tokens and objects. Fedora follows this standard and applications which refer to tokens such as smart cards or HSMs, must use
-RFC7512 to refer to them. Note that an application must not require the '''module-name''' and '''module-path''' URI elements. Compliant with this policy applications should resolve URIs which do not contain these elements based [[#Registered|on the registered provider modules]]. Applications must not require the "slot" attribute, nor print it, since it is an esoteric PKCS#11 module implementation information that has no meaning for the end-user, and in several modules its value is not guaranteed to be unique (and may change for example after system reboot).
-
-[#specify-object]
-== How to specify an object stored in a smart card/HSM
-
-https://tools.ietf.org/html/rfc7512[RFC7512] defines a 'PKCS#11 URI' as a standard way to identify tokens and objects. Fedora follows this standard and applications which refer to objects stored in smart cards or HSMs, must use RFC7512 to refer to certificates and private keys.
-
-In particular when PKCS#11 objects are specified in a textual form which is visible to the user ''(e.g. on the command line or in a config file)'', objects SHOULD be specified in the form of a PKCS#11 URI as as described in https://tools.ietf.org/html/rfc7512[RFC7512].
-
-This form is already accepted by some programs such as the OpenConnect VPN client. The certificate used in the above examples can be simply used as a client authentication certificate by adding the command-line option `-c 'pkcs11:manufacturer=piv_II;id=%01'`.
diff --git a/guidelines/modules/ROOT/pages/PkgConfigBuildRequires.adoc b/guidelines/modules/ROOT/pages/PkgConfigBuildRequires.adoc
deleted file mode 100644
index 015f340..0000000
--- a/guidelines/modules/ROOT/pages/PkgConfigBuildRequires.adoc
+++ /dev/null
@@ -1,29 +0,0 @@
-= BuildRequires: pkgconfig(foo) vs. foo-devel
-
-Fedora packages which use `+pkg-config+` to build against a library (e.g. 'foo') on which they depend, *SHOULD* express their build dependency correctly as `+pkgconfig(foo)+`.
-
-== Rationale
-
-The build infrastructure for a given package will often locate and use required libraries by using `+pkg-config+`.
-
-Thus, `+pkgconfig(foo)+` is the true statement of the build dependency, and is how it should be expressed in the spec file.
-
-For historical reasons, many packages seem to have a hard-coded "pass:q[`BuildRequires: foo-devel`]", with the name of the package which _currently_ provides the required pkgconfig module. This is fragile and less portable than simply expressing the real dependency. Where package names change, and/or a required pkgconfig module is later provided by a _different_ package, these hard-coded dependencies break.
-
-Note that it shall still be acceptable to require specific packages by name if they are required for some reason _other_ than a `+pkg-config+` module that they provide.
-
-== Example
-
-Packages which build against `+libproxy+` should contain the following:
-
-....
-BuildRequires: pkgconfig(libproxy-1.0)
-....
-
-... and _not_ the following:
-
-....
-BuildRequires: libproxy-devel
-....
-
-This way, if the `+libproxy-1.0.pc+` pkgconfig module is ever provided from a differently-named package (such as by PacRunner once its integration is complete, or by a '`+libproxy1+`' backward-compatibility package as has happened to a number of other libraries in the past), the dependency will continue to be correct.
diff --git a/guidelines/modules/ROOT/pages/Python.adoc b/guidelines/modules/ROOT/pages/Python.adoc
deleted file mode 100644
index 1fc5936..0000000
--- a/guidelines/modules/ROOT/pages/Python.adoc
+++ /dev/null
@@ -1,1923 +0,0 @@
-= Python Packaging Guidelines
-:last-reviewed: 2024-04-03
-
-////
-
-Additional style notes:
-
-- Normative points are at the beginnings of sections
-and include highlighted keywords like **MUST** or **SHOULD**.
-So, if a reader only wants the rules,
-they can skip remainders of sections
-(discussion, examples, clarifications, ...)
-without missing context.
-
-- Some sections have additional IDs
-(see https://docs.asciidoctor.org/asciidoc/latest/sections/custom-ids/ )
-to avoid breaking links to removed/renamed sections.
-
-- In text, macros appear as Literal Monospace with a leading percent sign.
-Use curly braces for value-like macros, but not command-like macros
-(for example: `%{version}` but `%autosetup` or `%check`).
-
-- The first mention of a macro generally links to the documentation.
-The link includes some non-monospace text, e.g. "the `+%{version}+` macro".
-(In the current Fedora docs style, links aren't visible in monospace text).
-
-- The documentation for a macro has the macro's name as ID.
-
-////
-
-
-This version of Python Packaging Guidelines
-is in effect since 2021
-and represents a major rewrite and paradigm shift.
-Not all packages are updated to reflect this.
-Older guidelines are kept as a historical reference,
-but new packages *MUST NOT* use them.
-Existing packages *MUST* migrate to the current Python guidelines:
-
-* xref:Python_201x.adoc[“201x-era” Python packaging guidelines]
-(Packages using these usually use the deprecated
-<<py3_install,`+%py3_install+`>>
-or <<py3_install_wheel,`+%py3_install_wheel+` macro>>
-or call `+setup.py install+`.)
-
-////
-NOTE: A summary of changes from the older guidelines
-is available at https://hackmd.io/@python-maint/rJmQQc4DP
-////
-
-NOTE: These guidelines only support current Fedora releases.
-For older releases (such as in EPEL 8),
-consult the xref:Python_201x.adoc[201x-era guidelines].
-
-The two <<Distro-wide guidelines>> below
-apply to all software in Fedora that uses Python at build- or run-time.
-
-The rest of the Guidelines apply to packages that ship code
-that can be imported with Python’s `+import+` statement.
-Specifically, that is all packages
-that install files under `+/usr/lib*/python*/+`.
-
-Except for the two “Distro-wide guidelines”,
-these Guidelines do not apply to simple one-file scripts or utilities,
-especially if these are included with software
-not written in Python.
-However, if an application (e.g. CLI tool, script or GUI app)
-needs a more complex Python library,
-the library *SHOULD* be packaged as an importable library
-under these guidelines.
-
-A major goal for Python packaging in Fedora is to
-_harmonize with the wider Python ecosystem_,
-that is,
-the https://pypa.io[Python Packaging Authority] (PyPA) standards
-and the https://pypi.org/[Python Package Index] (PyPI).
-Packagers *SHOULD* be prepared to get involved with upstream projects
-to establish best practices as outlined here.
-We wish to improve both Fedora and the wider Python ecosystem.
-
-NOTE: Some build tools (like CMake or autotools)
-may not work with the latest PyPA standards yet.
-(For example, they might generate `+.egg-info+` directories
-rather than `+.dist-info+`.)
-While this document's normative points (MUST/SHOULD) are tool-agnostic,
-many of the practical tips and helper macros will not be applicable.
-If this affects you, consider contacting the
-https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/[Python SIG]
-for guidance
-and/or following the xref:Python_201x.adoc[older guidelines]
-for the time being.
-
-NOTE: Fedora’s Python SIG not only develops these guidelines,
-but it’s also involved in PyPA standards and Python packaging best practices.
-Check out https://fedoraproject.org/wiki/SIGs/Python[the wiki] or
-https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/[mailing list]
-if you need help or wish to help out.
-
-== Distro-wide guidelines
-
-=== Build-time dependency on python3-devel
-
-*Every* package that uses Python (at run-time and/or build-time)
-and/or installs Python modules
-*MUST* have a build-time dependency on `+python3-devel+`,
-even if Python is not actually invoked during build-time.
-Such a package *MUST* use one of the following in its `+.spec+` file:
-
-* <<pyproject_buildrequires,`+%pyproject_buildrequires+`>>
-in the `+%generate_buildrequires+` section
-* `+BuildRequires: python3-devel+`
-
-Only having a transitive build-time dependency on `+python3-devel+` is not sufficient.
-If the package uses an alternate Python interpreter instead of `+python3+`
-(e.g. `+pypy+`, `+jython+`, `+python2.7+`),
-it *MAY* instead require the corresponding `+*-devel+` package.
-
-The `+*-devel+` package brings in relevant RPM macros.
-It may also enable automated or manual checks: for example,
-Python maintainers use this requirement to list packages
-that use Python in some way
-and might be affected by planned changes.
-
-=== Mandatory macros
-
-The following macros *MUST* be used where applicable.
-
-The expansions in parentheses are provided only as reference/examples.
-
-The macros are defined for you in all supported Fedora and EPEL
-versions.
-
-// Keep the list synced with "Macro Reference" below
-
-* `+%{python3}+` (`+/usr/bin/python3+`):
-The Python interpreter.
-For example, this macro should be
-used for invoking Python from a `+spec+` file script,
-passed to `+configure+` scripts to select a Python executable,
-or used as `+%{python3} -m pip+` to run a Python-based tool.
-+
-If the packaged software invokes Python at _run time_
-(as opposed to running Python to build/test it),
-it might be necessary to pass flags to `+%{python3}+`
-to isolate it from user-installed packages.
-See <<Shebangs>> for details.
-+
-* `+%{python3_version}+` (e.g. `+3.9+`, `+3.10+`):
-Version of the Python interpreter.
-+
-* `+%{python3_version_nodots}+` (e.g. `+39+`, `+310+`):
-Version of the Python interpreter without the dot.
-* `+%{python3_sitelib}+` (e.g. `+/usr/lib/python3.9/site-packages+`):
-Where pure-Python modules are installed.
-+
-* `+%{python3_sitearch}+` (e.g. `+/usr/lib64/python3.9/site-packages+`):
-Where Python extension modules (native code, e.g. compiled from C) are
-installed.
-
-The rest of this document uses these macros,
-along with `+%{_bindir}+` (`+/usr/bin/+`),
-instead of the raw path names.
-
-=== Python implementation support[[_multiple_python_runtimes]]
-
-Fedora primarily targets _CPython_,
-the reference implementation of the Python language.
-We generally use “Python” to mean CPython.
-
-Alternate implementations like `+pypy+` are available,
-but currently lack comprehensive tooling and guidelines for packaging.
-When targetting these, there are no hard rules
-(except the general Fedora packaging guidelines).
-But please try to abide by the _spirit_ of these guidelines.
-When in doubt, consider consulting the Python SIG.
-
-=== Python version support
-
-Fedora packages *MUST NOT* depend on other versions
-of the CPython interpreter
-than the current `+python3+`.
-
-In Fedora, Python libraries are packaged for a single version of Python,
-called `+python3+`.
-For example, in Fedora 32, `+python3+` is Python 3.8.
-
-In the past, there were multiple Python stacks,
-e.g. `+python3.7+` and `+python2.7+`,
-installable together on the same machine.
-That is also the case in some projects that build _on top_ of Fedora,
-like RHEL, EPEL and CentOS.
-Fedora might re-introduce parallell-installable stacks in the future
-(for example if a switch to a new Python version needs a transition period,
-or if enough interested maintainers somehow appear).
-
-Fedora does include alternate interpreter versions,
-e.g. `+python2.7+` or `+python3.5+`,
-but these are meant only for developers that need to test upstream code.
-Bug and security fixes for these interpreters only cover this use case.
-Packages such as `+pip+` or `+tox+`,
-which enable setting up isolated environments
-and installing third-party packages into them,
-*MAY*, as an exception to the rule above, use these interpreters
-as long as this is coordinated with the maintainers
-of the relevant Python interpreter.
-
-== Naming
-
-Python packages have several different names,
-which should be kept in sync but will sometimes differ
-for historical or practical reasons.
-They are:
-
-* the Fedora _source package name_ (or _component name_, `+%{name}+`),
-* the Fedora _built RPM name_,
-* the _project name_ used on https://pypi.org/[PyPI]
-or by https://pip.pypa.io[pip], and
-* the _importable module name_ used in Python
-(a single package may have multiple importable modules).
-
-Some examples (both good and worse):
-
-[cols=",,,",options="header",]
-|===
-|Fedora component |Built RPM |Project name |Importable module
-|`+python-requests+` |`+python3-requests+` |`+requests+` |`+requests+`
-|`+python-django+` |`+python3-django+` |`+Django+` |`+django+`
-|`+PyYAML+` |`+python3-pyyaml+` |`+pyyaml+` |`+yaml+`
-|`+python-ldap+` |`+python3-ldap+` |`+python-ldap+` |`+ldap+`, `+ldif+`, etc.
-|`+python-pillow+` |`+python3-pillow+` |`+pillow+` |`+PIL+`
-|`+python-jupyter-client+` |`+python3-jupyter-client+` |`+jupyter-client+` |`+jupyter_client+`
-|===
-
-Elsewhere in this text,
-the metavariables `+SRPMNAME+`, `+RPMNAME+`, `+PROJECTNAME+`, `+MODNAME+`
-refer to these names, respectively.
-
-=== Canonical project name
-
-Most of these names are case-sensitive machine-friendly identifiers,
-but the _project name_ has human-friendly semantics:
-it is case-insensitive
-and treats some sets of characters (like `+._-+`) specially.
-For automated use,
-it needs to be normalized to a canonical format
-used by Python tools and services such as setuptools, pip and PyPI.
-For example, the canonical name of the `+Django+` project
-is `+django+` (in lowercase).
-This normalization is defined in
-https://www.python.org/dev/peps/pep-0503/#normalized-names[PEP 503],
-and <<py_dist_name,the `+%{py_dist_name}+` macro>> implements it
-for Fedora packaging.
-The canonical name is obtained by switching the project name to lower case
-and converting all runs of non-alphanumeric characters to single “-” characters.
-Example: “The $$$ Tree” becomes “the-tree”.
-
-Elsewhere in this text,
-the metavariable `+DISTNAME+` refers to the canonical form of the project name.
-
-Note that in some places, the original,
-non-normalized project name must be used.
-For example,
-the <<pypi_source,`+%pypi_source+` macro>> and the `+%autosetup+` macro
-need `+Django+`, not `+django+`.
-
-=== Name limitations
-
-The character `pass:[+]` in names of built (i.e. non-SRPM) packages
-that include `+.dist-info+` or `+.egg-info+` directories
-is reserved for <<Extras>> and *MUST NOT* be used for any other purpose.
-
-As an exception, `pass:[+]` characters *MAY* appear at the _end_ of such names.
-
-The `pass:[+]` character triggers
-the automatic dependency generator for extras.
-
-Replace any `pass:[+]` signs in the upstream name with `+-+`.
-Omit `pass:[+]` signs on the beginning of the name.
-Consider adding `Provides` for the original name with `pass:[+]` characters
-to make the package easier to find for users.
-
-=== Library naming
-
-A built (i.e. non-SRPM) package for a _Python library_
-*MUST* be named with the prefix `+python3-+`.
-A source package containing primarily a _Python library_
-*MUST* be named with the prefix `+python-+`.
-
-The Fedora package’s name *SHOULD* contain
-the <<Canonical project name>>.
-If possible, the project name *SHOULD* be the same
-as the name of the main importable module,
-in lowercase,
-with underscores (`+_+`) replaced by dashes (`+-+`).
-
-If the importable module name and the project name do not match,
-users frequently end up confused.
-In this case, packagers *SHOULD* ensure that upstream is aware of the problem
-and (especially for new packages where renaming is feasible)
-strive to get the package renamed.
-The Python SIG is available for assistance.
-
-A _Python library_ is a package meant to be imported in Python,
-such as with `+import requests+`.
-Tools like _Ansible_ or _IDLE_, whose code is importable
-but not primarily meant to be imported from other software,
-are not considered libraries in this sense.
-So, this section does not apply for them.
-(See the
-xref:index#_libraries_and_applications[general Libraries and Applications guidelines]
-for general guidance.)
-
-The Fedora component (source package) name for a library
-should be formed by taking the _canonical project name_
-and prepending `+python-+` if it does not already start with `+python-+`.
-This may leads to conflicts
-(e.g. between https://pypi.org/project/bugzilla/[bugzilla]
-and https://pypi.org/project/python-bugzilla/[python-bugzilla]).
-In that case, ensure upstream is aware of the potentially confusing naming
-and apply best judgment.
-
-=== Application naming
-
-Packages that primarily provide applications, services
-or any kind of executables *SHOULD* be named
-according to the general xref:Naming.adoc[Fedora naming guidelines]
-(e.g. `+ansible+`).
-
-Consider adding a virtual provide according to <<Library naming>> above
-(e.g. `+python3-PROJECTNAME+`),
-if it would help users find the package.
-
-== Files to include
-
-=== Source files and bytecode cache[[_byte_compiling]]
-
-Packages *MUST* include the source file (`+*.py+`)
-*AND* the bytecode cache (`+*.pyc+`) for each pure-Python importable module.
-The source files *MUST* be included in the same package as the bytecode cache.
-
-Scripts that are not importable
-(typically ones in `+%{_bindir}+` or `+%{_libexecdir}+`)
-*SHOULD NOT* be byte-compiled.
-
-The cache files are found in a `+__pycache__+` directory
-and have an interpreter-dependent suffix like `+.cpython-39.pyc+`.
-
-The cache is not necessary to run the software,
-but if it is not found, Python will try to create it when a module is imported.
-If this succeeds, the file is not tracked by RPM
-and it will linger on the system after uninstallation.
-If it does not succeed, users can get spurious SELinux AVC denials in the logs.
-
-Normally, byte compilation (generating the cache files)
-is done for you by the `+brp-python-bytecompile+`
-xref:index.adoc#_brp_buildroot_policy_scripts[BRP script],
-which runs automatically
-after the `+%install+` section of the spec file has been processed.
-It byte-compiles any `+.py+` files that it finds
-in `+%{python3_sitelib}+` or `+%{python3_sitearch}+`.
-
-You must include these files of your package
-(i.e. in the `+%files+` section).
-
-If the code is in a subdirectory (importable package),
-include the entire directory:
-
-[source,spec]
-----
-%files
-%{python3_sitelib}/foo/
-----
-
-Adding the trailing slash is best practice for directories.
-
-However, this cannot be used for top-level modules (those directly in
-e.g. `+%{python3_sitelib}+`), because both `+%{python3_sitelib}+` and
-`+%{python3_sitelib}/__pycache__/+` are owned by Python itself. Here, the
-`+%pycached+` macro can help. It expands to the given `+*.py+` source file
-and its corresponding cache file(s). For example:
-
-[source,spec]
-----
-%files
-%pycached %{python3_sitelib}/foo.py
-----
-
-expands roughly to:
-
-[source,spec]
-----
-%files
-%{python3_sitelib}/foo.py
-%{python3_sitelib}/__pycache__/foo.cpython-3X{,.opt-?}.pyc
-----
-
-==== Manual byte compilation[[manual-bytecompilation]]
-
-If you need to bytecompile stuff
-outside of `+%{python3_sitelib}+`/`+%{python3_sitearch}+`,
-use the <<py_byte_compile,`+%py_byte_compile+` macro>>.
-
-For example,
-if your software adds `+%{_datadir}/mypackage+` to Python’s import path
-and imports package `+foo+` from there, you will need to compile `+foo+` with:
-
-[source,spec]
-----
-%py_byte_compile %{python3} %{buildroot}%{_datadir}/mypackage/foo/
-----
-
-=== Dist-info metadata
-
-Each Python package *MUST* include _Package Distribution Metadata_
-conforming to https://packaging.python.org/specifications/[PyPA specifications]
-(specifically,
-https://packaging.python.org/specifications/recording-installed-packages/[Recording installed projects]).
-
-The metadata *SHOULD* be included
-in the same subpackage as the main importable module,
-if there is one.
-
-This applies to libraries (e.g. `+python-requests+`)
-as well as tools (e.g. `+ansible+`).
-
-When software is split into several subpackages,
-it is OK to only ship metadata in one built RPM.
-In this case, consider working with upstream
-to also split the upstream project.
-
-The metadata takes the form of a `+.dist-info+` directory
-installed in `+%{python3_sitelib}+` or `+%{python3_sitearch}+`,
-and contains information that tools like
-https://docs.python.org/3/library/importlib.metadata.html[`+importlib.metadata+`]
-use to introspect installed libraries.
-
-For example, a project named `+MyLib+` with importable package `+mylib+`
-could be packaged with:
-
-[source,spec]
-----
-%files -p python3-mylib
-%{python3_sitelib}/mylib/
-%{python3_sitelib}/MyLib-%{version}.dist-info/
-%doc README.md
-%license LICENSE.txt
-----
-
-Note that some older tools instead put metadata in an `+.egg-info+` directory,
-or even a single file.
-This won’t happen if you use the `+%pyproject_wheel+` macro.
-If your package uses a build system
-that generates an `+.egg-info+` directory or file,
-please contact Python SIG.
-
-As an exception,
-the Python standard library *MAY* ship without this metadata.
-
-=== Explicit lists
-
-Packages *MUST NOT* own shared directories owned by Python itself,
-such as the top-level `+__pycache__+` directories
-(`+%{python3_sitelib}/__pycache__+`, `+%{python3_sitearch}/__pycache__+`).
-
-Similarly to the xref:index#_explicit_lists[general rule],
-packagers *SHOULD NOT* simply glob everything under a shared directory.
-
-In addition to the xref:index#_explicit_lists[general list],
-the following *SHOULD NOT* be used in `+%files+`:
-
-* `+%{python3_sitelib}/*+`
-* `+%{python3_sitearch}/*+`
-* `+%{python_sitelib}/*+`
-* `+%{python_sitearch}/*+`
-* `+%pyproject_save_files '*'+`
-* `+%pyproject_save_files +auto+`
-
-This rule serves as a check against common mistakes
-which are otherwise hard to detect.
-It does limit some possibilities for automation.
-
-The most common mistakes this rule prevents are:
-
-* installing a test suite system-wide as an importable module named `+test+`,
-which would then conflict with other such packages, and
-* upstream adding new unexpected importable modules –
-you should always check such changes for
-https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_common_conflicting_files_cases_and_solutions[conflicts],
-and keep the list of such files explicit and auditable.
-
-== PyPI parity
-
-Every Python package in Fedora *SHOULD* also be available
-on https://pypi.org[the Python Package Index] (PyPI).
-
-The command `+pip install PROJECTNAME+` *MUST*
-install the same package (possibly in a different version),
-install nothing,
-or fail with a reasonable error message.
-
-If this is not the case,
-the packager *SHOULD* contact upstream about this.
-The goal is to get the project name registered or blocked on PyPI,
-or to otherwise ensure the rule is followed.
-
-If your package is not or cannot be published on PyPI, you can:
-
-* Ask upstream to publish it
-* If you wish: publish it to PyPI yourself and maintain it
-* Ask mailto:python-devel@lists.fedoraproject.org[Python SIG]
-to _block_ the name on PyPI for you
-* Email mailto:admin@pypi.org[PyPI admins] to block the name for you,
-giving the project name and explaining the situation
-(for example: the package cannot currently be installed via `+pip+`).
-You can ask questions and discuss the process at the
-https://discuss.python.org/t/block-names/4045[Python Discourse].
-
-NOTE: Project names that were in Fedora but not on PyPI
-when these guidelines were proposed are _blocked_ from being uploaded to PyPI.
-This prevents potential trolls from taking them,
-but it also blocks legitimate owners.
-If your package is affected, contact the Python SIG or
-https://github.com/pypa/pypi-support/issues/new?labels=PEP+541&template=pep541-request.md&title=PEP+541+Request%3A+PROJECT_NAME[file a PyPA issue]
-and mention `+@encukou+`.
-
-If your package’s project name conflicts with a different package on PyPI,
-change the project name.
-As painful as it is,
-we need to use a single global namespace across the Python ecosystem.
-Software that is not written specifically for Fedora already expects
-that project names use the PyPI namespace:
-for example, if a third-party library identifies a dependency by name,
-we don’t want that dependency satisfied by an unrelated Fedora package.
-
-As always,
-xref:index.adoc#_general_exception_policy[specific exceptions]
-can be granted by the Packaging Committee.
-
-== Provides and requirements[[_provides]]
-
-=== Provides for importable modules[[_the_py_provides_macro]]
-
-For any module intended to be used in Python 3 with `+import MODNAME+`,
-the package that includes it *SHOULD* provide `+python3-MODNAME+`,
-with underscores (`+_+`) replaced by dashes (`+-+`).
-
-This is of course always the case if the package is named `+python3-MODNAME+`.
-If the subpackage has some other name,
-then add `+%py_provides python3-MODNAME+` explicitly.
-See the following section to learn about `+%py_provides+`.
-
-[#Automatic-unversioned-provides]
-=== Automatic python- and python3.X- provides
-
-For any `+FOO+`,
-a package that provides `+python3-FOO+` *SHOULD* use `+%py_provides+`
-or an automatic generator
-to also provide `+python-FOO+`
-and `+python3.X-FOO+`, where `+X+` is the minor version of the interpreter.
-
-The provide *SHOULD NOT* be added manually:
-if a generator or macro is not used,
-do not add the `+python-FOO+` / `+python3.X-FOO+` provides at all.
-
-This is done automatically for package names by a generator.
-If absolutely necessary, the generator can be disabled
-by undefining <<__pythonname_provides,the `+%__pythonname_provides+` macro>>.
-
-For provides that aren’t package names,
-or (for technical reasons) for packages without files,
-the generator will not work.
-For these cases, the following invocation will provide `+python3-FOO+`,
-`+python-FOO+` and `+python3.X-FOO+`:
-
-[source,spec]
-----
-%py_provides python3-FOO
-----
-
-Using the generator or macro is important, because the specific form of
-the provide may change in the future.
-
-[#Machine-readable-provides]
-=== Machine-readable provides[[_automatic_provides_with_a_standardized_name]]
-
-Every Python package *MUST* provide `+python3dist(DISTNAME)+`
-*and* `+python3.Xdist(DISTNAME)+`,
-where `+X+` is the minor version of the interpreter
-and `+DISTNAME+` is the <<Canonical project name>>
-corresponding to the <<Dist-info metadata>>.
-For example, `+python3-django+` would provide
-`+python3dist(django)+` and `+python3.9dist(django)+`.
-
-This is generated automatically from the dist-info metadata.
-The provide *SHOULD NOT* be added manually:
-if the generator fails to add it, the metadata *MUST* be fixed.
-
-These _Provides_ are used for automatically generated _Requires_.
-
-If absolutely necessary,
-the automatic generator can be disabled by undefining the
-<<__pythondist_provides,`+%{?__pythondist_provides}+` macro>>.
-Consider discussing your use case with the Python SIG if you need to do this.
-
-=== Dependencies
-
-As mentioned above,
-each Python package *MUST* explicitly BuildRequire `+python3-devel+`.
-
-Packages *MUST NOT* have dependencies (either build-time or runtime)
-with the unversioned prefix `+python-+`
-if the corresponding `+python3-+` dependency can be used instead.
-
-Packages *SHOULD NOT* have explicit dependencies
-(either build-time or runtime)
-with a minor-version prefix such as `+python3.8-+` or `+python3.8dist(+`.
-Such dependencies *SHOULD* instead be automatically generated
-or a macro should be used to get the version.
-
-Packages *SHOULD NOT* have an explicit runtime dependency on `+python3+`.
-
-Instead of depending on `+python3+`,
-packages have an automatic dependency on `+python(abi) = 3.X+`
-when they install files to `+%{python3_sitelib}+` or `+%{python3_sitearch}+`,
-or they have an automatic dependency on `+/usr/bin/python3+`
-if they have executable Python scripts,
-or they have an automatic dependency on `+libpython3.X.so.1.0()+`
-if they embed Python.
-
-These rules help ensure a smooth upgrade path
-when `+python3+` is updated in new versions of Fedora.
-
-[#Automatically-generated-dependencies]
-=== Automatically generated dependencies[[_requires_and_buildrequires_with_standardized_names]]
-
-Packages *MUST* use the automatic Python run-time dependency generator.
-
-Packages *SHOULD* use the opt-in build-dependency generator if possible.
-
-The packager *MUST* inspect the generated requires for correctness.
-All dependencies *MUST* be resolvable within the targeted Fedora version.
-
-Any necessary changes *MUST* be done by patches
-or modifying the source (e.g. with `+sed+`),
-rather than disabling the generator.
-The resulting change *SHOULD* be offered to upstream.
-As an exception, xref:AutoProvidesAndRequiresFiltering.adoc[filtering]
-*MAY* be used for temporary workarounds
-and xref:index.adoc#bootstrapping[bootstrapping].
-
-Dependencies covered by the generators *SHOULD NOT*
-be repeated in the `+.spec+` file.
-(For example, if the generator finds a `+requests+` dependency,
-then `+Requires: python3-requests+` is redundant.)
-
-The automatically generated requirements
-are in the form `+python3.Xdist(DISTNAME)+`,
-potentially augmented with version requirements or combined together
-with https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html[rich dependencies].
-Any `+.0+` suffixes are removed from version numbers
-to match the behavior of Python tools.
-(https://www.python.org/dev/peps/pep-0440/[PEP 440] specifies
-that `+X.Y+` and `+X.Y.0+` are treated as equal.)
-
-Note that the generators only cover Python packages.
-Other dependencies, often C libraries like `+openssl-devel+`,
-must be specified in the `+.spec+` file manually.
-
-Where the requirements are specified in the source
-depends on each project’s build system and preferences.
-Common locations are `+pyproject.toml+`, `+setup.py+`, `+setup.cfg+`,
-`+config.toml+`.
-
-==== Run-time dependency generator
-
-The automatic runtime dependency generator uses package metadata
-(as recorded in installed `+*.dist-info+` directories)
-to determine what the package depends on.
-
-In an emergency, you can opt-out from running the requires generator by
-<<python_disable_dependency_generator, adding `+%{?python_disable_dependency_generator}+`>>
-to the package (usually, just before the main package’s `+%description+`).
-
-==== Build-time dependency generator
-
-The opt-in (but strongly recommended) build-time dependency generator
-gathers information from
-https://www.python.org/dev/peps/pep-0517/#source-trees[`+pyproject.toml+` build-system information]
-(with fallback to `+setuptools+`) plus a standardized
-https://www.python.org/dev/peps/pep-0517/#get-requires-for-build-wheel[build-system hook]
-to gather further requirements.
-See <<pyproject_buildrequires,the `+%pyproject_buildrequires+` macro>>
-for more details.
-
-Note that without the `+-R+` flag, the generator will include run-time
-requirements in BuildRequires. This is useful for running tests and for
-checking that the dependencies are available in Fedora.
-
-=== Test dependencies
-
-See the <<Tests>> section.
-
-[#Extras]
-=== Extras[[_python_extras]]
-
-Python extras are a way for Python projects
-to declare that extra dependencies are required for additional functionality.
-
-For example,
-`+requests+` has several standard dependencies (e.g. `+urllib3+`).
-But it also declares an _extra_ named `+requests[security]+`,
-which lists additional dependencies (e.g. `+cryptography+`).
-Unlike RPM subpackages, extras can only specify additional dependencies,
-not additional files.
-The main package will work if the optional dependency is not installed,
-but it might have limited functionality.
-
-Python tools treat extras as virtual packages.
-For example, if a user runs `+pip install 'requests[security]'+`,
-or installs a project that depends on `+requests[security]+`,
-both `+requests+` and `+cryptography+` will be installed.
-
-In Fedora, extras are usually provided by packages with no files.
-Instead of square brackets,
-Fedora package names conventionally use the `pass:[+]` character
-(which is valid in RPM package names,
-but not in Python canonical project names nor in extras identifiers).
-
-==== Handling extras
-
-Python packages *SHOULD* have Provides
-for all extras the upstream project specifies, except:
-
-* those that are not useful for other packages
-(for example build/development requirements,
-commonly named `+dev+`, `+doc+` or `+test+`), and
-* those that have requirements that are not packaged in Fedora.
-
-A package that provides a Python extra
-*MUST* provide `+python3dist(DISTNAME[EXTRA])+`
-*and* `+python3.Xdist(DISTNAME[EXTRA])+`,
-where `+X+` is the minor version of the interpreter,
-`+DISTNAME+` is the <<Canonical project name>>,
-and `+EXTRA+` is the name of a single extra.
-For example, `+python3.9dist(requests[security])+`.
-These requirements *SHOULD* be generated
-using the automatic dependency generator.
-
-A package that provides a Python extra
-*MUST* require the extra’s main package with exact NEVR.
-
-A subpackage that primarily provides one Python extra *SHOULD* be named
-by appending `pass:[+]` and the extra name to the main package name.
-For example, `+python3-requests+security+`.
-
-The most straightforward way to provide an extra
-is with a dedicated subpackage containing no files (a “metapackage”).
-This case can be automated with
-the <<pyproject_extras_subpkg,`+%pyproject_extras_subpkg+` macro>>
-or the <<python_extras_subpkg,`+%python_extras_subpkg+` macro>>.
-
-This is not the only way:
-when some extra is always useful in a distro,
-it can be provided by the main package;
-when several extras are related,
-they may be provided by a single subpackage.
-However, having one dedicated subpackage per extra
-allows you to use the automatic dependency generator
-to ensure that the extras’ requirements will stay in sync with upstream.
-If you create a dedicated subpackage
-and want it to be always/usually installed,
-you can _Require_/_Recommend_/_Suggest_ it from the main package.
-
-The dependency generator for extras activates if the following holds:
-
-* The package name must end with `++EXTRA+`
-(where `+EXTRA+` is the extra name).
-* The package must contain the `+.dist-info+` directory, usually as `+%ghost+`.
-
-===== Example and convenience macros
-
-The extra subpackage for `+setuptools_scm[toml]+` can be specified
-using the `+%pyproject_extras_subpkg+` convenience macro as follows.
-The macro takes the main package name and name(s) of the extra(s):
-
-[source,spec]
-----
-%pyproject_extras_subpkg -n python3-setuptools_scm toml
-----
-
-If not using `+%pyproject_install+`,
-you will instead need to use `+%python_extras_subpkg+`
-and pass a path to the `+dist-info+` directory:
-
-[source,spec]
-----
-%python_extras_subpkg -n python3-setuptools_scm -i %{python3_sitelib}/*.dist-info toml
-----
-
-For this case,
-the extras dependency generator will read upstream metadata
-from the `+.dist-info+` directory.
-If it finds that the extra requires on `+toml+`,
-it will generate `+Requires: python3.Xdist(toml)+`
-and `+Provides: python3dist(setuptools-scm[toml])+`
-(and the corresponding `+python3.Xdist+` provide).
-
-If you need additional features
-that the `+*_extras_subpkg+` macros do not cover,
-you will need to write the subpackage sections manually.
-Such features can be, for example:
-
-* Obsoleting/providing other names (e.g. obsoleted extras packages)
-* Manual strong or weak dependencies on other
-(possibly non-Python) packages
-
-As an example of what you need to write in these cases,
-both of the `+*_extras_subpkg+` macro invocations above
-expand to the following:
-
-[source,spec]
-----
-%package -n python3-setuptools_scm+toml
-Summary: Metapackage for python3-setuptools_scm: toml extra
-Requires: python3-setuptools_scm = %{?epoch:%{epoch}:}%{version}-%{release}
-
-%description -n python3-setuptools_scm+toml
-This is a metapackage bringing in toml extra requires for python3-setuptools_scm.
-It contains no code, just makes sure the dependencies are installed.
-
-%files -n python3-setuptools_scm+toml
-%ghost %{python3_sitelib}/*.dist-info
-----
-
-Note that the dependency generator
-does not add a dependency on the main package
-(the `+Requires: python3-setuptools_scm = ...+` above).
-If you are not using the `+%python_extras_subpkg+` macro,
-you need to add it manually.
-
-==== Removing extras
-
-If an existing extra is removed from an upstream project,
-the Fedora maintainer *SHOULD* try to convince upstream to re-introduce it
-(with an empty list of dependencies).
-If that fails, the extra *SHOULD* be Obsoleted
-from either the main package or another extras subpackage.
-
-Note that removing extras is discouraged in
-https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html#optional-dependencies[setuptools documentation]
-(see the _Tip_ box near the end of the _Optional dependencies_ section).
-
-==== Automatic Requires for extras
-
-The automatic <<Run-time dependency generator>>
-will generate Requires on `+python3.Xdist(DISTNAME[EXTRA])+`
-from upstream `+Requires-Dist+` metadata.
-
-If the required package does not yet provide metadata for the extra,
-contact the Fedora maintainer to add it.
-
-In an emergency, you can define
-the <<_python_no_extras_requires,`+%_python_no_extras_requires+` macro>>
-to avoid automatically generating _all_ extras requirements.
-
-== Interpreter invocation
-
-=== Shebangs
-
-Shebang lines to invoke Python *MUST* use `+%{python3}+` as the interpreter.
-
-Shebang lines to invoke Python *SHOULD* be `+#!%{python3} -%{py3_shebang_flags}+`
-and they *MAY* include extra flags.
-
-If (some of) the default flags from
-<<py3_shebang_flags,the `+%{py3_shebang_flags}+` macro>> are not desirable,
-packages *SHOULD* explicitly redefine the macro to remove them by undefining
-the relevant `+%{_py3_shebang_...}+` macro.
-
-Using `+#!%{python3}+` (`+#!/usr/bin/python3+`)
-rather than e.g. `+#!/usr/bin/env python+`
-ensures that the system-wide Python interpreter is used to run the code,
-even if the user modifies `+$PATH+` (e.g. by activating a virtual environment).
-
-By default, `+-%{py3_shebang_flags}+` expands to `+-sP+`
-(or just `+-s+` on Python version lower than 3.11 and Fedora Linux older than 37).
-
-The `+-s+` flag,
-stored in <<_py3_shebang_s,the `+%{_py3_shebang_s}+` macro>>,
-means _don’t add user site directory to `+sys.path+`._
-That ensures the user’s Python packages
-(e.g. installed by `+pip install --user+`,
-or just placed in the current directory)
-don’t interfere with the RPM installed software.
-Sometimes, such content is desirable, such as with plugins.
-
-The `+-P+` flag,
-stored in <<_py3_shebang_P,the `+%{_py3_shebang_P}+` macro>>,
-means _don’t add the script's directory to `+sys.path+`._
-Sometimes, adding the script's directory to `+sys.path+` is desirable,
-such as with executable Python scripts installed in a custom directory,
-importing each other.
-
-Removing the undesired flag(s) from <<py3_shebang_flags,the `+%{py3_shebang_flags}+` macro>>
-rather than not using the macro at all,
-ensures that existing or future automation won’t add the flag.
-
-[source,spec]
-----
-# Remove -s from Python shebang - ensure that extensions installed with pip
-# to user locations are seen and properly loaded
-%undefine _py3_shebang_s
-----
-
-[source,spec]
-----
-# Don't add -P to Python shebangs
-# The executable Python scripts in /usr/share/opt-viewer/ import each other
-%undefine _py3_shebang_P 
-----
-
-The <<pyproject_install,`+%pyproject_install+` macro>>
-automatically changes all Python shebangs
-in `+%{buildroot}%{_bindir}/*+` to use `+%{python3}+`
-and add contents of the <<py3_shebang_flags,`+%{py3_shebang_flags}+` macro>>
-to the existing flags.
-If you’re not using that macro
-or you need to change a shebang in a different directory,
-you can use <<py3_shebang_fix,the `+%py3_shebang_fix+` macro>> as follows:
-
-[source,spec]
-----
-%py3_shebang_fix SCRIPTNAME …
-----
-
-=== Invokable Python modules
-
-Every executable `+TOOL+`
-for which the current version of Python matters
-*SHOULD* also be invokable by `+python3 -m TOOL+`.
-
-If the software doesn’t provide this functionality,
-packagers *SHOULD* ask the upstream to add it.
-
-This applies to tools that
-modify the current Python environment (like installing or querying packages),
-use Python for configuration,
-or use Python to run plugins.
-It does not apply to tools like GIMP or Bash
-which support plugins in multiple languages
-and/or have other means to specify the interpreter.
-
-For example, `+pip+` can be invoked as `+python3 -m pip+`.
-
-This allows users to accurately specify
-the Python version used to run the software.
-This convention works across different environments
-that might not always set `+$PATH+` or install scripts consistently.
-
-== Using Cython[[_packages_using_cython]]
-
-Tightening the
-xref:what-can-be-packaged.adoc#pregenerated-code[general Fedora policy],
-packages *MUST NOT* use files pre-generated by Cython.
-These *MUST* be deleted in `+%prep+` and regenerated during the build.
-
-As an exception, these sources *MAY* be used temporarily to prevent
-build time circular dependencies by following the
-xref:index.adoc#bootstrapping[bootstrapping guidelines].
-
-Generated files (the ones that must be deleted)
-have a generic `+.c+` or `+.cpp+` extension.
-Cython source files (which should stay)
-usually have the `+.pyx+` or `+.pxd+` extension.
-
-Cython is a popular tool for writing extension modules for Python.
-If compiles a Python-like language to C, which is then fed to the C compiler.
-Historically, Cython was hard to use upstream as a build-time dependency.
-Many projects include pre-generated C files in source
-distributions to avoid users from needing to install the tool.
-
-Cython uses CPython’s fast-changing internal API for performance reasons.
-For a new release of Python,
-Cython generally needs to be updated and the C files regenerated.
-In Fedora, this is frequently needed
-before upstreams release re-generated sources
-(e.g. for Alpha versins of Python).
-Since we do not have a problem with build-time dependencies,
-we always want to run the Cython step.
-
-For example, `+PyYAML+` removes a generated C file with:
-
-[source,spec]
-----
-rm -rf ext/_yaml.c
-----
-
-For another example, in `+python-lxml+` all C files are generated with Cython,
-which allows removing them with:
-
-[source,spec]
-----
-# Remove pregenerated Cython C sources
-find -type f -name '*.c' -print -delete
-----
-
-Some upstreams mix generated and hand-written C files.
-In such cases a grep like this one from `+scipy+` helps
-(but might not be entirely future proof):
-
-[source,spec]
-----
-# Remove pregenerated Cython C sources
-rm $(grep -rl '/\* Generated by Cython')
-----
-
-== Tests
-
-=== Running tests
-
-If a test suite exists upstream,
-it *SHOULD* be run in the `+%check+` section.
-If that is not possible with reasonable effort,
-at least a basic smoke test (such as importing the packaged module)
-*MUST* be run in `+%check+`.
-
-You *MAY* exclude specific failing tests.
-You *MUST NOT* disable the entire testsuite
-or ignore its result to solve a build failure.
-
-As an exception,
-you *MAY* disable tests with an appropriate `+%if+` conditional
-(e.g. https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html[bcond])
-when xref:index.adoc#bootstrapping[bootstrapping].
-
-Most errors in Python happen at run-time,
-so tests are extremely important to root out issues,
-especially when mass rebuilds are required.
-
-Common reasons for skipping tests in `+%check+` include requiring
-network access,
-dependencies not packaged in Fedora,
-and/or specialized hardware or resources.
-
-In these cases,
-you can use <<pyproject_check_import,the `+%pyproject_check_import+`>>
-or <<py3_check_import,the `+%py3_check_import+` macro>>
-to test that installed modules are importable.
-
-==== Tox
-
-A popular testing tool, and one which is well integrated in Fedora,
-is `+tox+`.
-Upstream, it is commonly used to test against multiple Python versions.
-In a Fedora package, BuildRequire test dependencies via `+%pyproject_buildrequires -t+` or `+-e+`
-(see _Test dependencies_ below)
-and run `+tox+` with:
-
-[source,spec]
-----
-%tox
-----
-
-This sets up the environment
-(`+$PATH+`, `+$PYTHONPATH+`, `+$TOX_TESTENV_PASSENV+`)
-and instructs `+tox+` to use the current environment rather than create new ones.
-For more options, see <<Build macros>>.
-
-==== pytest
-
-When upstream doesn’t use `+tox+`,
-the tests need to be run directly
-depending on upstream choice of a test runner.
-A popular runner is `+pytest+`, which can be invoked using `+%pytest+`.
-
-Use positional arguments to specify the test directory.
-See `+python3 -m pytest --help+` for how to select tests.
-For example, if network-related tests are marked “network”,
-you might use `+-m+` to deselect them:
-
-[source,spec]
-----
-%pytest -m "not network"
-----
-
-The `+%pytest+` macro sets several environment variables
-appropriate for `+%check+`:
-
-* Locations in the buildroot are added to `+$PATH+` and `+$PYTHONPATH+`.
-* `+$PYTHONDONTWRITEBYTECODE+` is set to avoid
-writing pytest-specific cache files to buildroot
-* `+$PYTEST_XDIST_AUTO_NUM_WORKERS+` is set to `+%{_smp_build_ncpus}+`
-* If unset, `+$CFLAGS+` and `+$LDFLAGS+` are set to match the build flags
-
-==== Other test runners
-
-If upstream doesn’t use `+tox+` or `+pytest+`,
-other test runners can be invoked with <<py3_test_envvars,the `+%{py3_test_envvars}+`>> macro,
-available since Fedora Linux 38.
-
-This macro sets several environment variables similarly to `+%pytest+`,
-but requires the actual test runner to be invoked after the macro, for example:
-
-[source,spec]
-----
-%{py3_test_envvars} %{python3} -m unittest
-----
-
-Or:
-
-[source,spec]
-----
-%{py3_test_envvars} %{python3} tests/run_tests.py
-----
-
-=== Test dependencies
-
-One part of the Python packaging ecosystem that is still not standardized
-is specifying test dependencies (and development dependencies in general).
-
-A good, common way for upstreams to specify test dependencies
-is using an <<Extras,extra>> like `+[test]+`, `+[testing]+` or `+[dev]+`.
-In this case, upstream’s instructions to install test dependencies
-might look like `+$ pip install -e.[test]+`.
-
-Another way to specify test dependencies is using a dedicated dependency group
-(https://www.python.org/dev/peps/pep-0735/[PEP 735]).
-
-Projects using `+tox+` usually specify test dependencies
-in a `+tox+`-specific format:
-a https://tox.readthedocs.io/en/latest/config.html#conf-requires[requires]
-key in the configuration.
-
-These three forms are handled by
-the <<pyproject_buildrequires,`+%pyproject_buildrequires+` macro>>.
-
-If upstream does not use either form,
-list test dependencies as manual _BuildRequires_ in the `+spec+` file,
-for example:
-
-[source,spec]
-----
-# Test dependencies:
-BuildRequires: python3dist(pytest)
-----
-
-If you need to do this,
-consider asking upstream to add a `+[test]+` extra or a `test` dependency group.
-
-=== Linters
-
-In `+%check+`, packages *SHOULD NOT* run “linters”:
-code style checkers,
-test coverage checkers
-and other tools that check code quality rather than functionality.
-
-Tools like `+black+`, `+pylint+`, `+flake8+`, or `+mypy+`
-are often “opinionated” and their “opinions” change frequently enough
-that they are nuisance in Fedora,
-where the linter is not pinned to an exact version.
-Furthermore, some of these tools take a long time
-to adapt to new Python versions,
-preventing early testing with Alpha and Beta releases of Python.
-And they are just not needed: wrongly formatted code is not important enough
-for the Fedora packager to bug the upstream about it.
-Making such an issue break a package build is entirely unreasonable.
-
-Linters _do_ make sense in upstream CI. But not in Fedora.
-
-If a linter is used, disable it and remove the dependency on it.
-If that is not easy, talk to upstream about making it easy
-(for example with a configuration option or a separate `+tox+` environment).
-
-For packages that contain such linters, use them at runtime or extend them,
-you will usually need to run the linter in `+%check+`.
-Run it to test functionality, not code quality of the packaged software.
-
-== Source files from PyPI
-
-Packages *MAY* use sources from PyPI.
-
-However, packages *SHOULD NOT* use an archive that omits test suites,
-licenses and/or documentation present in other source archives.
-
-For example, as of this writing `+pip+` provides a
-https://pypi.org/project/pip/#files[source tarball (“sdist”)]
-which omits the relatively large `+tests+` and `+docs+` directories 
-present in https://github.com/pypa/pip[the source on GitHub].
-In this case, the tarball from GitHub should be used.
-(See the xref:SourceURL#_git_tags[Git tags] section
-of Fedora SourceURL guidelines.)
-
-When using sources from PyPI,
-you can use the <<pypi_source,the `+%pypi_source+` macro>>
-to generate the proper URL.
-
-[[_version_warning]]
-WARNING: Some Python packages use metadata from `git`
-(or a similar version control system)
-to construct their version string,
-for example via https://pypi.org/project/setuptools-scm/[setuptools_scm].
-When publishing a package to PyPI,
-this version metadata is usually stored and included in a file,
-so the version control history is no longer needed to construct it.
-However, when using tarballs from a git forge directly,
-this version information is missing
-and must be manually provided by the packager.
-For example, the `SETUPTOOLS_SCM_PRETEND_VERSION` environment variable can be set
-to the desired value in the `+%generate_buildrequires+` and `+%build+` scripts in the spec file
-for packages that use `setuptools_scm` for this purpose.
-
-== Example spec file[[_example_python_spec_file]]
-
-The following is a viable spec file
-for a Python library called `+Pello+`
-that follows packaging best practices.
-
-Note that the project name `+Pello+` <<Canonical project name,normalizes>>
-to the lowercase `+pello+`.
-The example spec shows where each variant is typically used.
-
-The project has an <<Extras,extra>> `+color+`,
-which enables colorized output when installed.
-Since the required dependency is quite minimal
-and color improves the user experience,
-the extra is Recommended from the main package.
-
-[source,spec]
-----
-Name:           python-pello
-Version:        1.0.4
-Release:        1%{?dist}
-Summary:        Example Python library
-
-License:        MIT-0
-URL:            https://github.com/fedora-python/Pello
-Source:         %{url}/archive/v%{version}/Pello-%{version}.tar.gz
-
-BuildArch:      noarch
-BuildRequires:  python3-devel
-
-%global _description %{expand:
-A python module which provides a convenient example.
-This description provides some details.}
-
-%description %_description
-
-%package -n python3-pello
-Summary:        %{summary}
-Recommends:     python3-pello+color
-
-%description -n python3-pello %_description
-
-
-%pyproject_extras_subpkg -n python3-pello color
-
-%prep
-%autosetup -p1 -n Pello-%{version}
-
-
-%generate_buildrequires
-%pyproject_buildrequires -t
-
-
-%build
-%pyproject_wheel
-
-
-%install
-%pyproject_install
-
-# Here, "pello" is the name of the importable module.
-%pyproject_save_files -l pello
-
-
-%check
-%tox
-
-
-# Note that there is no %%files section for
-# the unversioned python module, python-pello.
-
-# For python3-pello, %%{pyproject_files} handles code files and %%license,
-# but executables and documentation must be listed in the spec file:
-
-%files -n python3-pello -f %{pyproject_files}
-%doc README.md
-%{_bindir}/pello_greeting
-
-
-%changelog
-----
-
-== Empty spec file
-
-The following is an unfinished spec file template to copy, paste and edit.
-
-[source,spec]
-----
-Name:           python-...
-Version:        ...
-Release:        0%{?dist}
-Summary:        ...
-
-License:        ...
-URL:            https://...
-Source:         %{url}/archive/v%{version}/...-%{version}.tar.gz / %{pypi_source ...}
-
-BuildArch:      noarch / BuildRequires:  gcc
-BuildRequires:  python3-devel
-
-%global _description %{expand:
-...}
-
-%description %_description
-
-%package -n python3-...
-Summary:        %{summary}
-
-%description -n python3-... %_description
-
-
-%prep
-%autosetup -p1 -n ...-%{version}
-
-
-%generate_buildrequires
-%pyproject_buildrequires -x... / -g... / -t
-
-
-%build
-%pyproject_wheel
-
-
-%install
-%pyproject_install
-%pyproject_save_files ...
-
-
-%check
-%tox / %pytest / %pyproject_check_import ...
-
-
-%files -n python3-... -f %{pyproject_files}
-%doc README.*
-%{_bindir}/...
-
-
-%changelog
-----
-
-== Macro Reference[[_macros]]
-
-This section documents macros that are available
-to help with Python packaging.
-The expansions in parentheses are provided only as reference/examples.
-
-See the <<Mandatory macros>> section above for:
-
-* `+%{python3}+` (`+/usr/bin/python3+`)
-* `+%{python3_version}+` (e.g. `+3.9+`)
-* `+%{python3_version_nodots}+` (e.g. `+39+`)
-* `+%{python3_sitelib}+` (e.g. `+/usr/lib/python3.9/site-packages+`)
-* `+%{python3_sitearch}+` (e.g. `+/usr/lib64/python3.9/site-packages+`)
-
-=== Shebang macros
-
-[#py3_shebang_flags]
-* `+%{py3_shebang_flags}+` (`+sP+` or `+s+` before Fedora Linux 37)
-+
-Flags for `+%{python3}+` to use in shebangs.
-See <<Shebangs>> for details.
-Includes flags from several `+%{_py3_shebang_...}+` macros listed here.
-
-[#_py3_shebang_s]
-* `+%{_py3_shebang_s}+` (`+s+`)
-+
-Undefine this macro to drop `+s+` from `+%{py3_shebang_flags}+`.
-
-[#_py3_shebang_P]
-* `+%{_py3_shebang_P}+` (`+P+`)
-+
-Undefine this macro to drop `+P+` from `+%{py3_shebang_flags}+`.
-Introduced in Fedora Linux 37.
-
-[#py3_shebang_fix]
-* `+%py3_shebang_fix PATHS+` (`+pathfix.py ... PATHS+`)
-+
-A macro to fix shebangs in specified `+PATHS+`.
-Only shebangs that already have `+python+` in them are changed.
-If a directory is given, all `+.py+` files in it are fixed, recursively.
-(So, if you need to fix shebangs in files not named `+*.py+`,
-you need to list each file separately or use a Shell glob,
-such as `+%{buildroot}%{_libexecdir}/mytool/*+`.)
-Existing flags are preserved and `+%{py3_shebang_flags}+` are added.
-+
-For example,
-`+#! /usr/bin/env python+` will be changed to `+#! /usr/bin/python3 -s+`
-and `+#! /usr/bin/python -u+` will be changed to `+#! /usr/bin/python3 -su+`.
-+
-This macro is called automatically
-by `+%pyproject_install+` on `+%{buildroot}%{_bindir}/*+`.
-
-=== Convenience macros
-
-[#pypi_source]
-* `+%{pypi_source PROJECTNAME [VERSION [EXT]]}+`
-(e.g. `+https://.../Django-3.0.5.tar.gz+`)
-+
-Evaluates to the appropriate URL for source archive hosted on PyPI.
-Accepts the project name and up to two optional arguments:
-+
---
-** The version of the PyPI project.
-Defaults to `+%version+` (the package version) with any `+~+` removed.
-** The file extension to use. Defaults to `+tar.gz+`.
---
-+
-In most cases it is not necessary to specify those two arguments.
-+
-For backward compatibility, the first argument is technically optional
-as well, but omitting it is deprecated. (It defaults to `+%srcname+` if
-defined, or to `+%pypi_name+` if defined, or to `+%name+`.)
-
-[#python3_platform]
-* `+%{python3_platform}+` (e.g. `+linux-x86_64+`)
-+
-The platform name.
-Used in some Python build systems.
-This corresponds to
-https://docs.python.org/3/library/sysconfig.html#sysconfig.get_platform[`+sysconfig.get_platform()+`].
-
-[#python3_ext_suffix]
-* `+%{python3_ext_suffix}+` (e.g. `+.cpython-39-x86_64-linux-gnu.so+`)
-+
-Filename extension for Python extension modules.
-This corresponds to the `+EXT_SUFFIX+`
-https://docs.python.org/3/library/sysconfig.html[sysconfig] variable.
-
-[#python3_platform_triplet]
-* `+%{python3_platform_triplet}+` (e.g. `+x86_64-linux-gnu+`)
-+
-A string identifying the architecture/platform.
-This corresponds to the `+MULTIARCH+`
-https://docs.python.org/3/library/sysconfig.html[sysconfig] variable.
-
-[#python3_cache_tag]
-* `+%{python3_cache_tag}+` (e.g. `+cpython-311+`)
-+
-Part of the bytecode cache filename that identifies the interpreter.
-This corresponds to the
-https://docs.python.org/3/library/sys.html#sys.implementation[`+sys.implementation.cache_tag+`]
-value.
-
-=== Build macros
-
-The “pyproject macros” are most useful
-for packaging Python projects that use the `+pyproject.toml+` file
-defined in https://www.python.org/dev/peps/pep-0518/[PEP 518]
-and https://www.python.org/dev/peps/pep-0517/[PEP 517],
-which specifies the package’s build dependencies
-(including the build system, such as `+setuptools+`, `+flit+` or `+poetry+`).
-
-If `+pyproject.toml+` is not found,
-the macros automatically fall backs to using `+setuptools+`
-with configuration in `+setup.cfg+`/`+setup.py+`.
-
-A full tutorial and discussion for the macros is available in the macros’
-https://src.fedoraproject.org/rpms/pyproject-rpm-macros/[README].
-
-[#pyproject_buildrequires]
-* `+%pyproject_buildrequires+`
-+
-Generate BuildRequires for the package.
-Used in the `+%generate_buildrequires+` section of the `+spec+` file.
-The macro has these options:
-+
-** `+-R+`: Don't include run-time requirements (e.g. if the build backend does not support this).
-** `+-r+`: Include run-time requirements
-(this flag is not needed and exists for backward-compatibility reasons only,
-run-time requirements are included by default).
-** `+-x EXTRA+`: Include dependencies given by the given <<Extras,extra>>.
-Cannot be used with `+-R+`.
-** `+-g GROUP+`: Include dependencies specified in the given dependency group
-(https://www.python.org/dev/peps/pep-0735/[PEP 735]).
-** `+-p+`: Read run-time dependencies from pyproject.toml [project] table.
-This reads also the [optional-dependencies] for the given <<Extras,extra>>.
-Cannot be used with `+-R+`.
-** `+-t+`: Include dependencies for the default _tox_ environment.
-Cannot be used with `+-R+`.
-** `+-e ENV+`: Include dependencies for the given _tox_ environment,
-and save the `+ENV+` name as `+%{toxenv}+`.
-Cannot be used with `+-R+`.
-Multiple comma separated values can be given, for example:
-+
-[source,spec]
-----
-%pyproject_buildrequires -e %{toxenv}-unit,%{toxenv}-integration
-----
-** Additional arguments are treated as paths to `+requirements.txt+` that are
-added on top of these dependencies
-
-[#pyproject_wheel]
-* `+%pyproject_wheel+`
-+
-Build the package.
-Commonly, this is the only macro needed in the `+%build+` section.
-+
-This macro needs BuildRequires generated by `+%pyproject_buildrequires+`.
-
-[#pyproject_install]
-* `+%pyproject_install+`
-+
-Install the package built by `+%pyproject_wheel+`.
-Calls `+%py3_shebang_fix %{_buildroot}%{_bindir}/*+`.
-+
-This macro needs BuildRequires generated by `+%pyproject_buildrequires+`.
-
-[#pyproject_save_files]
-* `+%pyproject_save_files MODNAME …+`
-+
-Generate a list of files corresponding to the given importable module(s)
-and save it as `+%{pyproject_files}+`.
-+
-Note that README file is not included.
-The LICENSE file is included when it is specified in the metadata.
-Also, while the macro allows including executable and other files
-(using the `+auto` flag),
-this feature *MUST NOT* be used in Fedora.
-+
-The `+MODNAME+` may be a glob pattern,
-which should be specific to your package.
-To prevent Shell from expanding the globs, put them in `+''+`,
-e.g. `+%pyproject_save_files '*pytest'+`.
-As mentioned in the <<Explicit lists>> section,
-expressions like `+%pyproject_save_files '*'+` are not acceptable.
-+
-The macro has these options:
-+
-** `+-l+`: Declare that a missing license should terminate the build.
-Packagers are encouraged to use this flag
-when the `%license file` is not manually listed in `%files`
-to avoid accidentally losing the file in a future version.
-** `+-L+`: Explicitly disable the check for a missing license file.
-When the `%license` file is manually listed in `%files`,
-packagers can use this flag to ensure future compatibility
-in case the `-l` behavior eventually becomes a default.
-** `+-M+`: Do not list any modules.
-When the package has no Python modules in it
-or when you need to list the modules in `+%files+` manually,
-this option allows to save just the non-module files
-(such as the `+.dist-info+` metadata directory).
-This option cannot be combined with `MODNAME`s.
-
-[#pyproject_files]
-* `+%{pyproject_files}+`
-+
-Path of the file written by `+%pyproject_save_files+`, to be used as:
-+
-[source,spec]
-----
-%files -n python3-DISTNAME -f %{pyproject_files}
-----
-
-=== Test macros
-
-[#tox]
-* `+%tox+`
-+
-Run tests using `+tox+`.
-+
-This macro needs BuildRequires generated by the `+-t+` or `+-e+` option of
-<<pyproject_buildrequires,the `+%pyproject_buildrequires+` macro>>.
-+
-Different environments may be specified with `+-e+`, for example:
-+
-[source,spec]
-----
-%check
-%tox %{?with_integration_tests:-e %{toxenv},%{toxenv}-integration}
-----
-+
-Flags for the `+tox+` command can be specified after `+--+`:
-+
-[source,spec]
-----
- %tox -- --parallel 0
-----
-+
-Additional arguments for the test runner may be specified after another `+--+`:
-+
-[source,spec]
-----
- %tox -- --parallel 0 -- --verbose tests/*
-----
-
-[#toxenv]
-*  `+%{toxenv}+`
-+
-The _tox_ environment(s) used by the `+%tox+` macro.
-Multiple environments are separated by commas.
-Can be overridden manually or with `+%pyproject_buildrequires -t ENV1,ENV2+`.
-
-[#default_toxenv]
-* `+%{default_toxenv}+` (e.g. `+py39+`)
-+
-The system-wide default value of `+%{toxenv}+`.
-
-[#pytest]
-* `+%pytest+`
-+
-Run `+%__pytest+` with environment variables appropriate for tests in `%check`.
-See <<Running tests>> for details.
-
-[#__pytest]
-* `+%__pytest+` (`+/usr/bin/pytest+`)
-+
-The command that `+%pytest+` uses. May be redefined.
-
-[#py3_test_envvars]
-* `+%py3_test_envvars+` (`+PATH=... PYTHONPATH=... PYTHONDONTWRITEBYTECODE=1 ...+`)
-+
-The environment variables used by `+%pytest+` and `+%tox+`.
-It may be used to invoke custom test runners in `+%check+`.
-See <<Other test runners>> for details.
-Introduced in Fedora Linux 38.
-
-[#py3_check_import]
-* `+%py3_check_import+`
-+
-Imports all provided modules.
-If running an upstream test suite is not feasible,
-use this macro in `+%check+` to test that public Python modules are importable.
-+
-Takes these arguments:
-+
---
-** `+-f+`: path to file containing qualified module names
-(separated by newlines).
-Optional, can be used multiple times.
-** `+-e+`: glob to exclude the matching module names.
-Optional, can be used multiple times.
-** `+-t+`: if set, import only top-level module names
-** Positional arguments (separated by spaces or commas)
-specify the module name(s) to check.
---
-+
-The macro sets various environment variables
-such as `+PATH+` and `+PYTHONPATH+`
-to ensure the packaged versions of modules are imported.
-
-[#pyproject_check_import]
-* `+%pyproject_check_import+`
-+
-Imports all public modules found by
-<<pyproject_save_files,the `+%pyproject_save_files+` macro>> whose names match
-any of the provided `+MODNAME+` globs.
-+
-This macro needs to be used with `+%pyproject_save_files+`
-(use `+%py3_check_import+` in other cases).
-+
-The macro takes `+-e+`/`+-t+` as well as
-positional arguments for `+%py3_check_import+` above.
-
-=== Extras macros
-
-[#pyproject_extras_subpkg]
-* `+%pyproject_extras_subpkg+`
-+
-Generates a simple subpackage for a Python extra.
-See <<Extras>> for more information.
-+
-This macro needs to be used with `+%pyproject_install+`
-(use `+%python_extras_subpkg+` in other cases).
-+
-Required arguments:
-+
---
-** `+-n+`: name of the “base” package (e.g. `+python3-requests+`)
-** Positional arguments (separated by spaces or commas): the extra name(s).
-Multiple metapackages are generated when multiple names are provided.
---
-+
-The macro also takes `+-i+`/`+-f+`/`+-F+` arguments
-for `+%python_extras_subpkg+` below,
-but if they are not given, a filelist written by `+%pyproject_install+` is used.
-+
-Similarly, the `+-a+`/`+-A+` flags are passed to `+%python_extras_subpkg+`.
-+
-This macro generates all the subpackage definition sections
-(`+%package+` including the `+Summary+` and `+Requires+` on the base package,
-`+%description+` and, by default, `+%files+`).
-Hence, it cannot be extended with custom _Provides_/_Obsoletes_/_Requires_/etc.
-This macro is designed to fit only the most common uses.
-For more complicated uses, construct the subpackage manually
-as shown in the <<Extras>> section.
-+
-The `+%files+` section is last.
-It can be continued to add files that only make sense with the extra
-and the base package does not fail without them.
-For example, the following macro will
-package the extra `+cli+` for the project `+a-cool-tool+`
-and include an `+a-cool-tool+` command:
-+
-[source,spec]
-----
-%pyproject_extras_subpkg -n a-cool-tool cli
-%{_bindir}/a-cool-tool
-----
-+
-Due to technical limitations,
-the macro never generates requirements on the arched
-`+BASE_PACKAGE%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}+`.
-It only adds
-`+Requires: BASE_PACKAGE = %{?epoch:%{epoch}:}%{version}-%{release})+`
-because a macro cannot reliably detect if the subpackage is arched or not.
-So far, this has not been a problem in practice.
-
-[#python_extras_subpkg]
-* `+%python_extras_subpkg+`
-+
-Generates a simple subpackage for a Python extra.
-See <<Extras>> for more information.
-Takes these arguments:
-+
---
-** `+-n+`: name of the “base” package (e.g. `+python3-requests+`)
-** `+-i+`: the `+%files %ghost+` path (glob) to the `+.dist-info+` directory
-** Positional arguments (separated by spaces or commas)
-specify the extra name(s)
-— multiple metapackages are generated when multiple names are provided.
-** `+-f+`: Relative path to the filelist for this metapackage
-(which should contain the `+%files %ghost+` path (glob)
-to the the metadata directory).
-Conflicts with `+-i+` and `+-F+`.
-** `+-F+`: Skip the %files section entirely
-(if the packager wants to construct it manually).
-Conflicts with `+-i+` and `+-f+`.
-** `+-a+`: Include `+BuildArch: noarch+` in the package definition,
-to be used only when the package is archful,
-but the “base” package passed to `+-n+` is not.
-** `+-A+`: Explicitly disables `+-a+` (does nothing at the moment).
---
-+
-As with `+%pyproject_extras_subpkg+`:
-+
-** This macro generates all the subpackage definition sections,
-with only `+%files+` being customizable.
-For more complicated uses, construct the subpackage manually
-as shown in the <<Extras>> section.
-** It never generates requirements on the arched
-`+BASE_PACKAGE%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}+`.
-
-=== Manual generation
-
-The following macros are available for cases where
-automatic generation is turned off.
-They can also be useful for handling files in non-standard locations
-where the generators don’t look.
-
-[#pycached]
-* `+%pycached MODNAME.py+`
-+
-Given a Python file, lists the file and the files with its bytecode
-cache. See _Source files and bytecode cache_ for more information.
-
-[#py_provides]
-* `+%py_provides python3-MODNAME+`
-+
-Generates `+Provides+` for `+python3-MODNAME+`, `+python3.X-MODNAME+`
-and `+python-MODNAME+`.
-See <<Automatic-unversioned-provides>> for more details.
-
-[#py_byte_compile]
-* `+%py_byte_compile INTERPRETER PATH+`
-+
-Byte-compile a Python file into a `+__pycache__/*.pyc+`.
-+
-If the `+PATH+` argument is a directory,
-the macro will recursively byte compile all `+*.py+` files in the directory.
-(So, if you need to compile files not named `+*.py+`,
-you need to use the macro on each file separately.)
-+
-The `+INTERPRETER+` determines the compiled file name’s suffix
-and the magic number embedded in the file.
-These muct match the interpreter that will import the file.
-Usually, the `+INTERPRETER+` should be set to `+%{python3}+`.
-If you are compiling for a non-default interpreter,
-use that interpreter instead and add a `+BuildRequires+` line for it.
-
-[#py_dist_name] 
-* `+%{py_dist_name PROJECTNAME}+`
-+
-Given a _project name_ (e.g. `+PyYAML+`) it will convert it
-to the canonical format (e.g. `+pyyaml+`).
-See <<Canonical project name>> for more information.
-
-[#py3_dist] 
-* `+%{py3_dist PROJECTNAME …}+`
-+
-Given one or more _project names_,
-it will convert them to the canonical format
-and evaluate to `+python3dist(DISTNAME)+`,
-which is useful when listing dependencies.
-See <<Machine-readable-provides>> for more information.
-
-=== System Settings
-
-The following macros can be redefined for special use cases.
-
-[#__python] 
-* `+%{__python}+` (errors by default if not redefined)
-+
-Defining this macro sets the meaning of all “unversioned” Python macros
-such as `+%{python}+` or `+%{python_sitelib}+`.
-Don’t use these macros without redefining `+%{__python}+`.
-
-[#__python3]
-* `+%{__python3}+` (`+/usr/bin/python3+`)
-+
-The python 3 interpreter.
-Redefining this macro changes all the `+%{python3...}+` macros,
-e.g. `+%{python3}+` or `+%{python3_sitelib}+`.
-
-[#python3_pkgversion]
-* `+%{python3_pkgversion}+` (`+3+`)
-+
-Distro-wide Python version, i.e. the `+3+` in `+python3+`.
-Projects that build on top of Fedora might define it to e.g. `+3.9+`
-to try allowing multiple Python stacks installable in parallel.
-Packages in Fedora *MAY* use it
-(e.g. in package names: `+python%{python3_pkgversion}-requests+`),
-but *MUST NOT* redefine it.
-
-=== Comparing Python versions
-
-When comparing Python versions
-(e.g. to ask: is `+%{python3_version}+` greater than 3.8?),
-using naïve `+%if %{python3_version} > 3.8+`
-or `+%if "%{python3_version}" > "3.8"+` is not possible,
-because the comparison is performed alphabetically on strings.
-Hence it is true that `+"3.10" < "3.8"+` (which is not desired).
-
-It is possible to explicitly compare version literals by using the `+v+` prefix,
-similar to the Python string prefixes:
-
-[source,spec]
-----
-%if v"0%{?python3_version}" > v"3.8"
-...
-%endif
-----
-
-[NOTE]
-====
-As a workaround for compatibility with RPM releases up to 4.16 (EPEL 9),
-`+%{python3_version_nodots}+` can be compared as an integers:
-
-[source,spec]
-----
-%if 0%{?python3_version_nodots} > 39
-...
-%endif
-----
-
-This will work with Python 3.10 (310 > 39),
-but eventually break with Python 4.0 (40 < 310).
-====
-
-=== Disabling automation
-
-The following macros can turn off Python-specific automation.
-
-Consider contacting the Python SIG if you need to do this.
-
-[#python_disable_dependency_generator]
-* `+%{?python_disable_dependency_generator}+`
-+
-Disables the automatic dependency generator.
-See <<Automatically-generated-dependencies>> for details.
-
-[#__pythonname_provides]
-* `+%undefine __pythonname_provides+`
-+
-Disables automatic generation of unversioned/versioned provides for package names,
-e.g. `+python-FOO+` and `+python3.9-FOO+` for `+python3-foo+`.
-See <<Automatic-unversioned-provides>> for more details.
-
-[#__pythondist_provides]
-* `+%undefine __pythondist_provides+`
-+
-Disables automatic generation of machine-readable Provides,
-e.g. `+python3dist(foo)+`.
-See <<Machine-readable-provides>> for more details.
-
-[#_python_no_extras_requires]
-* `+%global _python_no_extras_requires 1+`
-+
-If defined, <<Automatic Requires for extras>> will not be generated.
-
-[#_python_dist_allow_version_zero]
-* `+%global _python_dist_allow_version_zero 1+`
-+
-From Fedora Linux 38 on, it is no longer possible to build a Python package with version 0
-to prevent <<_version_warning,an accidental loss of the actual version information>>.
-If defined, the macro will allow to build such package.
-
-=== Deprecated Macros
-
-The following macros are deprecated.
-See the xref:Python_201x.adoc[201x-era Python Packaging guidelines]
-for how some of them were used.
-
-* [[py3_build]] `+%py3_build+`
-* [[py3_build_wheel]] `+%py3_build_wheel+`
-* [[py3_build_egg]] `+%py3_build_egg+`
-* [[py3_install]] `+%py3_install+`
-* [[py3_install_wheel]] `+%py3_install_wheel+`
-* [[py3_install_egg]] `+%py3_install_egg+`
-* [[py3dir]] `+%py3dir+`
-* [[py3_other_build]] `+%py3_other_build+`
-* [[py3_other_install]] `+%py3_other_install+`
-* [[python_provide]] `+%python_provide+`
diff --git a/guidelines/modules/ROOT/pages/Python_201x.adoc b/guidelines/modules/ROOT/pages/Python_201x.adoc
deleted file mode 100644
index b694172..0000000
--- a/guidelines/modules/ROOT/pages/Python_201x.adoc
+++ /dev/null
@@ -1,532 +0,0 @@
-= Python Packaging Guidelines (201x-era)
-:last-reviewed: 2020-08-05
-
-[IMPORTANT]
-====
-These guidelines were replaced by xref:Python.adoc[a newer version].
-
-They exist as a historical reference for packages that don't follow the new guidelines yet.
-====
-
-== Python Version Support
-
-In Fedora we have multiple Python runtimes,
-one for each supported major Python release.
-At this point that's one for python3.x and one for python2.7.
-However the Python 2 stack will be removed from Fedora and is xref:deprecating-packages.adoc[deprecated].
-Upstream support for the python2 interpreter officially ends in 2020.
-If a piece of software supports python3,
-it MUST be packaged for python3.
-Software using python2 MUST NOT be newly packaged into Fedora without FESCo exception.
-
-For guidelines on maintaining already existing python2 packages, see the xref:Python_Appendix.adoc[appendix].
-
-== Multiple Python Runtimes
-
-On Fedora `/usr/bin/python` is, if it is installed, a symbolic link to `/usr/bin/python3`.
-It was a symbolic link to `/usr/bin/python2` on previous releases.
-
-Packages in Fedora MUST NOT use `/usr/bin/python`. Instead packages for Python 3 MUST use `/usr/bin/python3` (even if upstream supports both Python 2 and 3). As a result of that `/usr/bin/python` (as well as `/usr/bin/env python` and similar) MUST NOT be used in shebang lines or as a dependency of a package. All uses of unversioned python executables in shebang lines will fail the build.
-These shebangs MUST be fixed (for example by using the `+%py3_shebang_fix+` macro in the spec file).
-If it is necessary to disable the checks, please see the information in xref:index#_shebang_lines[Shebang lines].
-
-All Python runtimes have a virtual provide for `+python(abi) = $MAJOR.$MINOR+`. For example, the Python 3.7 runtime package has:
-
-....
-$ rpm -q --provides python3 | grep abi
-python(abi) = 3.7
-....
-
-Python modules using these runtimes should have a corresponding "Requires" line on the Python runtime that they are used with. This is done automatically for files below `+/usr/lib[^/]*/python${PYVER}+`
-
-Mirroring the policy for regular packages, the Python-version-specific subpackages of your package MUST NOT be removed in a release branch of Fedora.
-
-== Naming
-
-The source package for a Python library MUST be named with the `python-` prefix. A built package however must include the Python major version in the name, using the `python3-` prefix. This is accomplished by adding a subpackage. See example below.
-
-This rule does not apply to applications.
-
-The character `+` in names of built packages (i.e. non-SRPM)
-that include `.dist-info` or `.egg-info` directories is reserved for <<Python Extras>> and MUST NOT be used for any other purpose.
-The `+` character triggers the automatic dependency generator for extras.
-Replace any `+` signs in the upstream name with `-`,
-or omit them when at the beginning of the name.
-As an exception, `+` characters are permitted at the _end_ of the name.
-
-== Dependencies
-
-Packages building for Python 3 will need `BuildRequires: python3-devel`.
-Most of them will also need `BuildRequires: python3-setuptools`.
-When in doubt, inspect the `setup.py` file for `setuptools` import.
-
-Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned `python-` prefix. Dependencies on Python packages instead MUST use names beginning with `python3-`.
-
-=== Automatically generated dependencies
-
-Packages MAY use the automatic Python dependency generator. This generator uses upstream egg/dist metadata (such as https://python-packaging.readthedocs.io/en/latest/dependencies.html[setuptool's install_requires]) to determine what the package should depend on. The generator parses the installed metadata from `+/usr/lib(64)?/pythonX.Y/site-packages/[^/]+++.(egg|dist)-info/requires.txt+`, so it will not work with software that uses plain https://docs.python.org/3/distutils/[distutils].
-
-This generates run time requires in the form of `+pythonX.Ydist(foo)+`. If the generated dependencies are not accurate, additional ones can still be added manually. To remove some, a packager MAY modify upstream-provided metadata (usually specified in the `setup.py` file) in the `+%prep+` section of the specfile or fall back to xref:AutoProvidesAndRequiresFiltering.adoc[filtering] those dependencies.
-
-The packager MUST inspect the generated requires for correctness. All dependencies MUST be resolvable within the targeted Fedora version.
-
-As an example, the upstream notebook package has (as of version 5.6.0):
-
-[source,python]
-----
-install_requires = [
-    'jinja2',
-    'tornado>=4',
-    'pyzmq>=17',
-    'ipython_genutils',
-    'traitlets>=4.2.1',
-    'jupyter_core>=4.4.0',
-    'jupyter_client>=5.2.0',
-    'nbformat',
-    'nbconvert',
-    'ipykernel',
-    'Send2Trash',
-    'terminado>=0.8.1',
-    'prometheus_client'
-],
-----
-
-And the resulting dependencies:
-
-....
-python3.7dist(ipykernel)
-python3.7dist(ipython-genutils)
-python3.7dist(jinja2)
-python3.7dist(jupyter-client) >= 5.2
-python3.7dist(jupyter-core) >= 4.4
-python3.7dist(nbconvert)
-python3.7dist(nbformat)
-python3.7dist(prometheus-client)
-python3.7dist(pyzmq) >= 17
-python3.7dist(send2trash)
-python3.7dist(terminado) >= 0.8.1
-python3.7dist(tornado) >= 4
-python3.7dist(traitlets) >= 4.2.1
-....
-
-Note that any `+.0+` suffixes are removed from version numbers to match the behavior of Python tools.
-(https://www.python.org/dev/peps/pep-0440/#final-releases[PEP 440] specifies that `+X.Y+` and `+X.Y.0+` are treated as equal.)
-
-This generator is enabled by default in Fedora. If a packager wishes to explicitly opt out of the generator because the upstream metadata are not applicable, a packager SHOULD opt out explicitly by adding:
-
-`+%{?python_disable_dependency_generator}+`
-
-Although this statement can be used anywhere in the spec, we recommend putting it just before the main package's `+%description+` declaration.
-
-=== Python Extras
-
-https://www.python.org/dev/peps/pep-0508/#extras[Python extras] are a way for Python projects to declare that extra dependencies are required for additional functionality.
-
-For example, `requests` has several standard dependencies (e.g. `urllib3`).
-But it also declares an _extra_ named `+requests[security]+`,
-which lists additional dependencies (e.g. `cryptography`).
-Unlike RPM subpackages,
-extras can only specify additional dependencies,
-not additional files.
-The main package will work if the optional dependency is not installed,
-but it might have limited functionality.
-
-Python tools treat extras as virtual packages.
-For example,
-if a user runs `+pip install requests[security]+`,
-or installs a project that depends on `+requests[security]+`,
-both `requests` and `cryptography` will be installed.
-
-Starting with Fedora 33,
-extras are usually provided by packages with no files.
-Instead of square brackets,
-Fedora package names conventionally use the `+` character to separate the package name and the _extra_ name,
-e.g. the package would be named `python3-requests+security`.
-The plus sign is valid in RPM package names,
-but not in Python canonical project names nor in extras identifiers.
-
-Python packages SHOULD have `Provides` for all extras the upstream project specifies,
-except those that are not useful for other packages
-(for example build/development requirements,
-commonly named `dev`, `doc` or `test`).
-
-A package that provides a Python extra MUST provide `+python3dist(…[…])+` and `+python3.Xdist(…[…])+`,
-for example, `+python3.9dist(requests[security])+`.
-These requirements SHOULD be generated using the automatic dependency generator.
-
-A package that provides a Python extra MUST require the extra's main package with exact NEVR.
-
-A subpackage that primarily provides one Python extra SHOULD be named by appending `+` and the extra name to the main package name.
-For example, `++python3-requests+security++`.
-
-The most straightforward way to provide an extra is with a dedicated subpackage containing no files (a "metapackage").
-This case can be automated with the `+%python_extras_subpkg+` macro.
-
-Alternative approach:
-when some extra is always useful in a distro,
-it can be provided by the main package;
-when several extras are related,
-they may be provided by a single subpackage.
-However,
-having one dedicated subpackage per extra
-allows you to use the automatic dependency generator to ensure that the extras' requirements will stay in sync with upstream.
-If you create a dedicated subpackage and want it to be always/usually installed, you MAY Require/Recommend/Suggest it from the main package.
-
-The dependency generator for extras activates if the following holds:
-
-- The package must contain the `.egg-info`/`.dist-info` directory, usually as `+%ghost+`.
-- The package name must end with `+EXTRA` (where `EXTRA` is the extra name).
-
-As an example,
-the extra subpackage for `+requests[security]+` can be specified using the `+%python_extras_subpkg+` convenience macro as follows.
-The macro takes the main package name and name(s) of the extra(s) as well as path to the `.egg-info` or `.dist-info` directory:
-
-----
-%{?python_extras_subpkg:%python_extras_subpkg -n python3-requests -i %{python3_sitelib}/*.egg-info security}
-----
-
-For this case,
-the extras dependency generator will read upstream metadata from the `.egg-info` directory.
-If it finds that the `security` extra has a dependency on `cryptography`,
-it will generate `+Requires: python3.Xdist(cryptography)+`,
-`+Provides: python3dist(requests[security])+`
-(and the corresponding `+python3.Xdist+` variant).
-
-If you need additional features that the `+%python_extras_subpkg+` macro does not cover,
-you will need to write the subpackage sections manually.
-Such features can be, for example:
-
-- Obsoleting/providing other names (e.g. obsoleted extras packages)
-- Manual strong or weak dependencies on other (possibly non-Python) packages
-- Including files excluded from the main package (if such files only make sense with the extra and the base package does not fail without them)
-
-As an example of what you need to write in these cases,
-the `+%python_extras_subpkg+` macro invocation above expands to the following:
-
-----
-%package -n python3-requests+security
-Summary: Metapackage for python3-requests: security extras
-Requires: python3-requests = %{?epoch:%{epoch}:}%{version}-%{release}
-%description -n python3-requests+security
-This is a metapackage bringing in security extras requires for python3-requests.
-It contains no code, just makes sure the dependencies are installed.
-
-%files -n python3-requests+security
-%ghost %{python3_sitelib}/*.egg-info
-----
-
-Note that the dependency generator does not add a dependency on the main package
-(the `+Requires: python3-setuptools_scm = ...+` above).
-If you are not using the `+%python_extras_subpkg+` macro,
-you need to add it manually.
-
-NOTE: The `+%python_extras_subpkg+` can take multiple extras names to generate multiple packages.
-For more options, see the https://fedoraproject.org/wiki/Changes/PythonExtras[change proposal which introduced this].
-
-== Provides
-
-For any module `foo` intended to be used in Python 3 with `import foo`,
-the package that includes it *should* provide `python3-foo`.
-This is of course always the case if the subpackage is named `python3-foo`
-(as in the examples below).
-If the subpackage has some other name,
-then `Provides: python3-foo` should be added explicitly
-(via `+%py_provides python3-foo+`, see below).
-
-=== The %py_provides macro
-
-All packages that provide `+python3-...+` (for any `+...+`) SHOULD also provide `+python-...+` and `+python3.X-...+`.
-Starting from Fedora 33,
-most of the Python packages named `+python3-...+` will provide such names automatically via the dependency generator in `/usr/lib/rpm/fileattrs/pythonname.attr`.
-
-Any manually added virtual provides of `+python3-...+` SHOULD be done via the `+%py_provides+` macro.
-
-Instead of:
-
-----
-Provides: python3-pkg_resources = %{version}-%{release}
-----
-
-Do:
-
-----
-%py_provides python3-pkg_resources
-----
-
-Optionally,
-supply a custom `epoch:version-release` as a second argument to `+%py_provides+`.
-
-On releases older than Fedora 33,
-or (for technical limitations) for packages without files,
-it is necessary to use `+%py_provides+` even for package names:
-
-----
-%package -n python3-%{srcname}
-Summary: %{summary}
-%py_provides python3-%{srcname}
-----
-
-Packagers SHOULD try to remove explicit `+%py_provides+` calls for package names,
-but MAY preserve them if they aim for compatibility with older releases or packages without files.
-
-NOTE: Historically, there was `+%python_provide+` macro with similar but different semantics.
-It still works for compatibility reasons but it is deprecated and SHOULD NOT be used
-and packagers SHOULD replace is with appropriate `+%py_provides+` call.
-
-== Automatic Provides with a standardized name
-
-When building a Python package, RPM looks for `+.dist-info+` and `+.egg-info+` files or directories in the `+%files+` sections of all packages. If one or more are found, RPM parses them to find the *standardized name* (i.e. dist name, name on PyPI) of the packaged software, and then automatically creates two `+Provides:+` tags in the following format:
-
-....
-Provides: python3.Ydist(CANONICAL_STANDARDIZED_NAME)
-Provides: python3dist(CANONICAL_STANDARDIZED_NAME)
-....
-
-The `+3.Y+` is the Python version used (usually 3.6 and higher), and between the parentheses is the name of the software in a *canonical format* used by Python tools and services such as setuptools, pip and PyPI. The canonical name is obtained by switching the standardized name to lower case and converting all runs of non-alphanumeric characters to single “-” characters. Example: “The $$$ Tree” becomes “the-tree”.
-
-=== Requires and BuildRequires with standardized names
-
-These Provides tags can be used to list Requires and BuildRequires of a package using the _standardized names_ (i.e. dist name, name on PyPI) of Python modules. To make it easier, you can use the `+%{py3_dist}+` macro that accept one or more parameters: the _standardized name(s)_ of the desired Python software. It will convert the name(s) to the _canonical format_ and create the proper `+python3dist(...)+` tag(s).
-
-In addition, you can use the `+%{py_dist_name}+` macro that simply transforms any _standardized name_ to the _canonical format_.
-
-For example:
-
-....
-BuildRequires: %{py3_dist PyMySQL} >= 0.7.5
-# => BuildRequires: python3dist(pymysql) >= 0.7.5
-
-Requires: %{py3_dist virtualenv pyPEG2}
-# => Requires: python3dist(virtualenv) python3dist(pypeg2)
-
-%{py_dist_name 0-._.-._.-._.-._.-._.-._.-0}
-# => 0-0
-....
-
-== Source Files from PyPI
-
-When packaging software which is available from PyPI, you can make use of the `+%pypi_source+` macro. This macro accepts from zero to three arguments and evaluates to an appropriate URL for the source file on PyPI. The arguments are:
-
-1.  The name of the PyPI project. Defaults to `+%srcname+` if defined, or to `+%pypi_name+` if defined, or to `+%name+` (the package name).
-2.  The version of the PyPI project. Defaults to `+%version+` (the package version) with any `~` characters removed  (used for alpha/beta/dev versions in RPM version but not in Python package version).
-3.  The file extension to use. Defaults to `tar.gz`.
-
-In most cases it is not necessary to specify any arguments.
-
-== Macros
-
-The following macros are defined for you in all supported Fedora and EPEL releases:
-
-[%header,cols=3*]
-|===
-|Macro
-|Expanded path
-|Notes
-
-|`+%{__python}+`
-|(Error)
-|Don't use this macro without redefining it. Defining it changes the meaning of other "unversioned" Python macros such as `+%{python}+` or `+%{python_sitelib}+`.
-
-
-|`+%{__python3}+`
-|`+/usr/bin/python3+`
-|Python 3 interpreter. Redefining this macro changes all the `+%{python3...}+` macros.
-
-|`+%{python3}+`
-|`+%{__python3}+`
-|Python 3 interpreter. Use this macro in spec files.
-
-|`+%py_provides+`
-|(Lua script)
-|See <<The %py_provides macro>> for detailed explanation.
-
-|`+%{python3_sitelib}+`
-|`+/usr/lib/python3.X/site-packages+`
-|Where pure python3 modules are installed.
-
-|`+%{python3_sitearch}+`
-|`+/usr/lib64/python3.X/site-packages+` on 64bit architectures (e.g. x86_64) and `+/usr/lib/python3.X/site-packages+` on 32bit.
-|Where python3 extension modules (e.g. C compiled) are installed.
-
-|`+%{py_byte_compile}+`
-|(script)
-|See xref:Python_Appendix.adoc#manual-bytecompilation[byte-compiling] section for usage.
-
-|`+%{python3_version}+`
-|`+3.X+`
-|Python 3 version. Useful when running programs with Python version in filename, such as `+nosetests-%{python3_version}+`.
-
-|`+%{python3_version_nodots}+`
-|`+3X+`
-|Python 3 version without dots. Useful when listing files explicitly in %files section, such as `+%{python3_sitearch}/foo/_speedups.cpython-%{python3_version_nodots}*.so+`
-
-|`+%{python3_platform}+`
-|`+linux-x86_64+` on x86_64
-|The platform name used in Python, useful for specifying `+$PYTHONPATH+`, such as `+PYTHONPATH=build/lib.%{python3_platform}-%{python3_version}+`
-
-|`+%{python3_ext_suffix}+`
-|`+.cpython-3X-x86_64-linux-gnu.so+` on x86_64
-|The usual suffix of Python extension modules, useful when listing files. Note that extension modules can alternatively have a simple `+.so+` suffix as well, depending on how they are built.
-
-|`+%py3_build+`
-|`+%{__python3} setup.py build …+`
-|See `+%py3_install+` for passing arguments to `+setup.py build+` or directly to `+setup.py+`.
-
-|`+%py3_install+`
-|`+%{__python3} setup.py install --skip-build …+`
-|Various flags are passed to `+setup.py install+`, see `/usr/lib/rpm/macros.d/macros.python3` for details and similar macros. To add extra flags/arguments to `+setup.py install+`, separate them with `+--+`, for example: `+%py3_install -- --install-scripts %{_libexecdir}+`. To pass custom command line arguments directly to `+setup.py+`, define `+%py_setup_args+`.
-
-|`+%__pytest+`
-|`+/usr/bin/pytest+`
-|The `pytest` command used in `+%pytest+`. Don't use this macro directly, but feel free to redefine it for usage in `+%pytest+` if desired.
-
-|`+%pytest+`
-|`+PATH=… PYTHONPATH=… … %{__pytest}+`
-|Various environment variables are set to ensure the packaged version is tested. Use this macro instead of direct `pytest` calls in `+%check+`. Pass additional argument as if passed to `pytest`, e.g. `+%pytest -m "not network"+` to deselect tests marked as `network`.
-
-|`+%py3_check_import …+`
-|`+PATH=… PYTHONPATH=… … %{__python3} -c 'import …'+`
-|Various environment variables are set to ensure the packaged version is tested. Use this macro in `+%check+` to test public Python modules are importable if running upstream tests suite is not feasible. Pass module names as positional arguments separated by spaces or commas.
-
-|`+%{py_dist_name}+`
-|(Lua script)
-|Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format. See <<Automatic Provides with a standardized name>> for more information.
-
-|`+%{py3_dist}+`
-|(Lua script)
-|Given a standardized name (i.e. dist name, name on PyPI) of Python software, it will convert it to a canonical format, and evaluates to `+python3dist(CANONICAL_NAME)+`, which is useful when listing dependencies. See <<Automatic Provides with a standardized name>> for more information.
-
-|`+%{pypi_source}+`
-|(Lua script)
-|Evaluates to the appropriate URL for the package. See above for more information.
-
-|`+%pycached ….py+`
-|(Lua script)
-|Given a Python file, lists the file and the files with its bytecode cache. See <<Byte compiling>> for more information.
-
-|`+%{py3_shebang_flags}+`
-|`s`
-|The default set of flags for Python shebangs. Redefine this to change the set. Used by `+%py3_shebang_fix+`.
-
-|`+%py3_shebang_fix …+`
-|(Python script)
-|Given paths for Python files or directories with them, it changes Python shebangs to `+#! %{__python3}+`, preserves any existing flags (if found) and adds flags defined in `+%{py3_shebang_flags}+` (if not already present).
-
-|===
-
-During `+%install+` or when listing `+%files+` you can use the `+%{python3_sitearch}+` and `+%{python3_sitelib}+` macros to specify where the installed modules are to be found. For instance:
-
-....
-%files
-# A pure python3 module
-%{python3_sitelib}/foomodule/
-# A compiled python3 extension module
-%{python3_sitearch}/barmodule/
-....
-
-Use of the macros has several benefits:
-
-* It ensures that the packages are installed correctly on multilib architectures.
-* Using these macros instead of hardcoding the directory in the specfile ensures your spec remains compatible with the installed Python version even if the directory structure changes radically (for instance, if `+python3_sitelib+` moves into `+%{_datadir}+`).
-
-== Packages using Cython
-
-A great amount of extension modules for Python
-(Python modules written in a compiled language such as C or C++)
-are written using the https://cython.org/[Cython] language and compiler.
-
-Majority of such packages contains the generated C (or C++) sources in the source tarball.
-
-Tightening the xref:what-can-be-packaged.adoc#_pregenerated_code[general Fedora policy],
-packages MUST NOT use pre-generated Cython sources.
-They MUST be deleted in `%prep` and regenerated during the build.
-
-Any exception to this rule should be considered a xref:index.adoc#bootstrapping[bootstrapping].
-
-== Files to include
-
-When packaging Python modules, several types of files are included:
-
-* +*.py+ source files because they are used when generating tracebacks.
-* +*.pyc+ byte compiled files.
-** Python will try to create them at runtime if they don't exist which leads to spurious SELinux AVC denials in the logs.
-** If the system administrator invokes Python with -OO, they will be created with no docstrings. This can break some programs.
-* +*.egg-info+ or +*.dist-info+ files or directories. If these are generated by the module's build scripts they must be included in the package because they might be needed by other applications and modules at runtime.
-
-The source files MUST be included in the same package as the byte compiled versions.
-
-Packagers SHOULD NOT simply glob everything under the sitelib or sitearch directories. The following SHOULD NOT be used:
-
-* `+%{python3_sitelib}/*+`
-* `+%{python3_sitearch}/*+`
-* `+%{python_sitelib}/*+`
-* `+%{python_sitearch}/*+`
-
-And packages MUST NOT include the top-level `+__pycache__+` directory (see below).
-
-== Byte compiling
-
-Python will automatically try to byte compile files when it runs in order to speed up startup the next time it is run. These files are saved in files with the extension of .pyc (compiled Python). These files will be located inside a directory named `+__pycache__+`.
-
-The .pyc files contain byte code that is portable across OSes. If you do not include them in your packages, Python will try (and generally fail) to create them when the user runs the program. If the system administrator runs the program, then the files will be successfully written, causing stray .pyc files which will not be removed when the package is removed. To prevent that the byte compiled files need to be compiled and included in the `+%files+` section. Normally, byte compilation is done for you by the `+brp-python-bytecompile+` script. This script runs after the `+%install+` section of the spec file has been processed and byte compiles any .py files that it finds in `+%{python3_sitelib}+` or `+%{python3_sitearch}+` (this recompilation puts the proper filesystem paths into the modules otherwise tracebacks would include the `+%{buildroot}+` in them).
-
-You must include the .pyc files in your package. If the build process creates a `+__pycache__+` directory in a subdirectory of `+%{python3_sitearch}+` or `+%{python3_sitelib}+`, you must also include all items in the `+__pycache__+` directory. You MUST NOT include the directories `+%{python3_sitearch}/__pycache__+` or `+%{python3_sitelib}/__pycache__+` because they are already owned by the python3-libs package.
-
-All that you need to do is include the files in the `+%files+` section (replacing `+%{python3_sitelib}+` with the appropriate macro for your package):
-
-....
-%files
-%{python3_sitelib}/foo/
-....
-
-or, if the Python code installs directly into `+%{python3_sitelib}+`, use the `+%pycached+` macro to include the bytecode cache files:
-
-....
-%files
-%pycached %{python3_sitelib}/foo.py
-....
-
-That evaluates roughly to
-
-....
-%files
-%{python3_sitelib}/foo.py
-%{python3_sitelib}/__pycache__/foo.cpython-%{python3_version_nodots}{,.opt-?}.pyc
-....
-
-NOTE: The `+%pycached+` macro only supports Python 3.5+,
-so for older Python versions
-(such as 3.4 in EPEL 6 or 7),
-you need to list the files manually.
-
-NOTE: In case you need to use other macros with the `+%pycached+` macro,
-such as `+%exclude+` or `+%ghost+`,
-pass the other macro as part of the argument to `+%pycached+`.
-For example:
-`+%pycached %exclude /path/to/foo.py+`
-Using the macros in wrong order would only apply `+%exclude+` to the first entry that `+%pycached+` generates.
-
-=== Manual byte compilation
-
-For more details on the internals of byte compilation, please see xref:Python_Appendix.adoc#manual-bytecompilation[the appendix].
-
-== Example Python spec file
-
-The following is a very simple spec file for a Python module.
-
-.python-example.spec
-[source]
-----
-include::{examplesdir}/python-example.spec[]
-----
-
-== Reviewer checklist
-
-The following briefly summarizes the guidelines for reviewers to go over:
-
-* *Must*: Python modules must be built from source. They cannot simply drop an egg or whl from upstream into the proper directory. (See xref:what-can-be-packaged.adoc#prebuilt-binaries-or-libraries[prebuilt binaries Guidelines] for details).
-* *Must*: Python modules must not download any dependencies during the build process.
-* *Must*: When building a compat package, it must install using easy_install -m so it won't conflict with the main package.
-* *Must*: When building multiple versions (for a compat package) one of the packages must contain a default version that is usable via "import MODULE" with no prior setup.
-* *Should*: Additional `+python3-...+` provides should be accomplished via a `+%py_provides+` call.
-* *Should*: A package which is used by another package via an egg interface should provide egg info.
diff --git a/guidelines/modules/ROOT/pages/Python_Appendix.adoc b/guidelines/modules/ROOT/pages/Python_Appendix.adoc
deleted file mode 100644
index 01d4631..0000000
--- a/guidelines/modules/ROOT/pages/Python_Appendix.adoc
+++ /dev/null
@@ -1,114 +0,0 @@
-= Additional Python Guidelines
-:last-reviewed: 2020-01-01
-
-Here are some additional Python-related guidelines, moved here in order to keep the main page manageable.
-
-[#manual-bytecompilation]
-== Manual byte compilation
-
-NOTE: This section only applies for the 201x-era guidelines.
-In the new guidelines, see the
-xref:Python.adoc#manual-bytecompilation[Manual byte compilation] section.
-
-When byte compiling a .py file, python embeds a magic number in the byte compiled files that correspond to the runtime. Files in `+%{python?_sitelib}+` and `+%{python?_sitearch}+` MUST correspond to the runtime for which they were built. For instance, a pure Python module compiled for the 3.4 runtime MUST be below `+%{_usr}/lib/python3.4/site-packages+`
-
-The `+brp-python-bytecompile+` script tries to figure this out for you.
-The script determines which interpreter to use when byte compiling the module
-by checking what directory the file is installed in.
-If it's `+/usr/lib{,64}/pythonX.Y+`,
-then `+pythonX.Y+` is used to byte compile the module.
-If `+pythonX.Y+` is not installed,
-then an error is returned and the rpm build process will exit on an error
-so remember to `+BuildRequire+` the proper python package.
-
-If you have `+*.py+` files outside of the `+/usr/lib(64)?/pythonX.Y/+` directories
-and you require those files to be byte compiled
-(e.g. it's an importable Python module)
-you MUST compile them explicitly using the `+%py_byte_compile+` macro.
-Note that not all Python files are importable Python modules;
-when in doubt, grep the sources for the appropriate import statement.
-
-An example for a package that has both Python versions:
-
-....
-# Buildrequire both python2 and python3
-BuildRequires: python2-devel python3-devel
-
-%install
-# Installs a python2 private module into %{buildroot}%{_datadir}/mypackage/foo
-# and installs a python3 private module into %{buildroot}%{_datadir}/mypackage/bar
-make install DESTDIR=%{buildroot}
-
-# Manually invoke the python byte compile macro for each path that needs byte
-# compilation.
-%py_byte_compile %{python2} %{buildroot}%{_datadir}/mypackage/foo
-%py_byte_compile %{python3} %{buildroot}%{_datadir}/mypackage/bar
-....
-
-The `+%py_byte_compile+` macro takes two arguments.
-The first is the python interpreter to use for byte compiling.
-The second is a file or directory to byte compile.
-If the second argument is a directory,
-the macro will recursively byte compile any *.py file in the directory.
-
-== Manual byte compilation for EPEL 6 and 7
-
-The script interpreter defined in `+%{__python}+` is used to compile the modules outside of `+/usr/lib(64)?/pythonX.Y/+` directories. This defaults to `+/usr/bin/python+` (that's Python 2.6 or on EPEL 6 and 2.7 on EPEL 7). If you need to compile the modules for python3, set it to `+/usr/bin/python3+` instead:
-
-....
-%global __python %{python3}
-....
-
-Doing this is useful when you have a python3 application that's installing a private module into its own directory. For instance, if the foobar application installs a module for use only by the command line application in `+%{_datadir}/foobar+`. Since these files are not in one of the python3 library paths (i.e., `+/usr/lib/python3.6+`) you have to override `+%{__python}+` to tell `+brp-python-bytecompile+` to use the python3 interpreter for byte compiling.
-
-These settings are enough to properly byte compile any package that builds Python modules in `+%{python?_sitelib}+` or `+%{python?_sitearch}+` or builds for only a single Python interpreter. However, if the application you're packaging needs to build with both python2 and python3 and install into a private module directory (perhaps because it provides one utility written in python2 and a second utility written in python3) then you need to do this manually. Here's a sample spec file snippet that shows what to do:
-
-....
-# Turn off the brp-python-bytecompile script
-%global __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')
-# Buildrequire both python2 and python3
-BuildRequires: python2-devel python3-devel
-[...]
-
-%install
-# Installs a python2 private module into %{buildroot}%{_datadir}/mypackage/foo
-# and installs a python3 private module into %{buildroot}%{_datadir}/mypackage/bar
-make install DESTDIR=%{buildroot}
-
-# Manually invoke the python byte compile macro for each path that needs byte
-# compilation.
-%py_byte_compile %{python2} %{buildroot}%{_datadir}/mypackage/foo
-%py_byte_compile %{python3} %{buildroot}%{_datadir}/mypackage/bar
-....
-
-Note that this *does disable* the compilation of files in `+/usr/lib(64)?/pythonX.Y/+`.
-
-== Byte compilation reproducibility
-
-This subsection only applies to Fedora <= 40, ELN, and EPEL.
-In later Fedora releases, this is implemented automatically.
-
-For two Python files with the exact same content and metadata,
-byte compilation might produce different results.
-The resulting `.pyc` files are functionally identical but are not bit-by-bit identical.
-In most cases,
-internal Python reference counter is here to blame because it might have a different internal state during each byte compilation.
-If you want a deeper explanation,
-take a look at https://bugzilla.redhat.com/show_bug.cgi?id=1686078#c2[this Bugzilla comment].
-
-This inconvenience might cause a problem in Koji where noarch packages built as a part of an arch build might be rejected because they have different content.
-
-To work around this issue,
-BuildRequire marshalparser `BuildRequires: /usr/bin/marshalparser`
-(a tool that makes `.pyc` files more reproducible)
-and instruct it to process the `.pyc` files in certain paths by setting the `+%py_reproducible_pyc_path+` macro:
-
-....
-%global py_reproducible_pyc_path %{buildroot}%{_datadir}/llamafarm/plugins
-....
-
-With that setting,
-marshalparser recursively finds all byte-compiled Python files in `+%{buildroot}%{_datadir}/llamafarm/plugins+` and attempts to fix them.
-This happens at the very end of the build process when all previous byte compilation steps are finished.
-If marshalparser cannot parse some of the cache files,
-the build fails.
diff --git a/guidelines/modules/ROOT/pages/R.adoc b/guidelines/modules/ROOT/pages/R.adoc
deleted file mode 100644
index 7abc3ed..0000000
--- a/guidelines/modules/ROOT/pages/R.adoc
+++ /dev/null
@@ -1,292 +0,0 @@
-= R Packaging Guidelines
-
-http://www.r-project.org/[R] is a language and environment for statistical computing and graphics.
-R is similar to the award-winning S system, which was developed at Bell Laboratories by John Chambers et al.
-It provides a wide variety of statistical and graphical techniques
-(linear and nonlinear modelling, statistical tests, time series analysis, classification, clustering, ...).
-
-R is designed as a true computer language with control-flow constructions for iteration and alternation,
-and it allows users to add additional functionality by defining new functions.
-For computationally intensive tasks, C, C++ and Fortran code can be linked and called at run time.
-For more info, see http://cran.r-project.org/doc/manuals/R-intro.html[An introduction to R].
-
-This document covers how to handle R "add-on packages" for inclusion in Fedora's repositories.
-For a complete example, see the <<Example spec file>> below.
-
-////
-[TIP]
-====
-The https://pagure.io/r2spec[R2spec] tool can be used to generate spec files automatically from standard https://cran.r-project.org/[CRAN]-like repositories.
-It is designed to produce spec files that are compliant with these R Packaging Guidelines.
-====
-////
-
-== Naming
-
-The canonical source of R packages is https://cran.r-project.org/[CRAN], the "Comprehensive R Archive Network".
-The are additional CRAN-like repositories for specific fields,
-such as https://bioconductor.org/[Bioconductor] (Bioc for short) for bioinformatics.
-But since they are designed to be complementary, package names do not conflict with each other.
-
-R add-ons *MUST* be packaged with `R-$pkg` as the name of the source package,
-where `$pkg` is the name of the project on the upstream CRAN-like repository,
-i.e. the package https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#The-DESCRIPTION-file[DESCRIPTION]'s `Package` field.
-This `$pkg` name *MUST* be exactly as written upstream, including case distinctions and dots.
-Also:
-
-* The spec's `Summary` field *SHOULD* match the package DESCRIPTION's `Title` field.
-* The spec's `Description` field *SHOULD* match the package DESCRIPTION's `Description` field.
-
-== Versioning
-
-Since upstream versions may contain characters that are invalid in RPM version strings, they *MUST* be translated to be RPM-compatible.
-Particularly, it is common for R packages to specify patch versions using the hyphen as the separator, e.g. `1.2-3`.
-Such hyphens *MUST* be converted to a dot.
-This translation *SHOULD* be done via the `+%R_rpm_version+` macro as follows:
-
-----
-Version: %R_rpm_version 1.2-3
-----
-
-Apart from defining `+%{version}+` as `1.2.3` in this case, this macro sets `+%__R_upstream_version+` to keep track of the upstream version for URL generation.
-
-== License
-
-Typically, R packages do not contain license files per CRAN policy.
-R allows and ships a set of open source licenses,
-and R packages just declare which one they adhere to in the DESCRIPTION file.
-Following this policy, and as an exception to the general Licensing Guidelines,
-we do not require upstream R packages to add additional license files.
-
-[NOTE]
-====
-Full text licenses can be found under `/usr/share/R/licenses`.
-These texts can also be displayed in the R console using the `RShowDoc()` function.
-====
-
-== Sources
-
-Projects from standard CRAN-like repositories *MUST* be packaged from the sources that are published there.
-Packages from the following repositories *MUST* use the set macros provided for automatic generation of the project's URL and package's source URL:
-
-* CRAN: `+%{cran_url}+` and `+%{cran_source}+`
-* Bioc: `+%{bioc_url}+` and `+%{bioc_source}+`
-
-The URLs above correspond to the default _software_ repositories.
-Bioconductor provides additional repositories that can be specified via an argument:
-
-* AnnotationData: `+%{bioc_url data/annotation}+` and `+%{bioc_source data/annotation}+`
-* ExperimentData: `+%{bioc_url data/experiment}+` and `+%{bioc_source data/experiment}+`
-* Workflows: `+%{bioc_url workflows}+` and `+%{bioc_source workflows}+`
-
-== Architectures
-
-Packages that do not contain architecture-specific code (i.e. no compiled parts), *MUST* set `BuildArch: noarch`.
-
-[NOTE]
-====
-This affects the installation path:
-
-* `+%{_datadir}/R/library/$pkg+` for noarch packages;
-* `+%{_libdir}/R/library/$pkg+` otherwise;
-
-but this is automatically handled by RPM macros as described below.
-====
-
-== Dependencies
-
-=== Automatic standardized names
-
-All R packages will automatically produce standardized `Requires` and `Provides` via a generator in `R-rpm-macros`:
-
-* `Provides` are in the form `R($pkg) = $version`;
-* `Requires` are in the form `R($pkg)`, with optional `>= $version` as specified in the package's metadata if supplied;
-
-where `$pkg` is the upstream package name, and `$version` is the RPM-compatible version as described in <<Versioning>>.
-
-The packager *MUST* inspect the generated `Requires` for correctness.
-All hard dependencies (R's `LinkingTo`, `Depends`, `Imports`) *MUST* be resolvable within the targeted Fedora version.
-
-=== BuildRequires
-
-Packages *MUST* declare `BuildRequires: R-devel`, which in turn pulls the necessary `R-rpm-macros` and sets the development environment (compilers, libraries, etc.).
-
-[NOTE]
-====
-Note that R packages inherit their compilation flags from the main R package, which stores them in `+%{_libdir}/R/etc/Makeconf+`.
-The design of R is such that all R add-on packages use the same optimization flags that the main R package was built with.
-Accordingly, this is why R addon packages do not pass `+%{optflags}+`.
-====
-
-If other libraries and utilities (e.g. cmake) are required for building, they *MUST* be declared explicitly as `BuildRequires`.
-
-Build-time dependencies on other R packages are automatically handled by the `+%R_buildrequires+` macro, which *MUST* be called in the `+%generate_buildrequires+` scriptlet.
-
-[NOTE]
-====
-* All hard dependencies (R's `LinkingTo`, `Depends`, `Imports`) are declared as `BuildRequires` using standardized names (see <<Automatic standardized names>>).
-* Soft dependencies (R's `Suggests`, `Enhances`) are skipped, except for packages used to develop the test suite (see <<Dynamic BuildRequires>>).
-====
-
-=== Bundled dependencies
-
-Following the general guidelines, packages *SHOULD* unbundle other dependencies found in R package sources whenever possible.
-Whenever bundled dependencies are used, they *MUST* be declared with virtual `Provides`.
-
-=== Sub-packages
-
-Some R packages expose header files under the standard path `R/library/$pkg/include` (defined by CRAN and expected by R), so that other packages can link to them via `LinkingTo`.
-The https://cran.r-project.org/package=Rcpp[Rcpp] package is a notable example.
-Sometimes, these headers are required at build-time, sometimes at build- as well as run-time and therefore they are essential for proper functioning.
-For these and a variety of other reasons, these headers *MUST NOT* be split off into a `-devel` sub-package.
-
-If a particular package contains a large number of examples or documentation that do not impact the package's functionality, these parts *MAY* be split off into a sub-package,
-but sub-packages in general are highly discouraged.
-
-== Walkthrough
-
-=== Preparing the sources
-
-The rest of the scriptlets expect package sources to be extracted in a subdirectory named after the package.
-Therefore, in `+%prep+`, the call to `+%setup+` or `+%autosetup+` *MUST* set the `-c` option.
-
-----
-%prep
-%autosetup -c
-----
-
-Other code for unbundling, fixes and workarounds *MAY* be placed here.
-
-=== Dynamic BuildRequires
-
-The `+%R_buildrequires+` macro *MUST* be called in the `+%generate_buildrequires+` scriptlet to generate the dynamic `BuildRequires`.
-
-----
-%generate_buildrequires
-%R_buildrequires
-----
-
-Testing packages such as `testthat`, which are declared in `Suggests`, are whitelisted in `+%{__R_whitelist}+`,
-and added as `BuildRequires` by `+%R_buildrequires+`.
-
-[IMPORTANT]
-====
-Currently, only the most common testing suites available in Fedora are supported:
-
-`testthat|tinytest|RUnit|testit`
-====
-
-Using other `Suggests` in the tests *SHOULD* be considered a bug.
-However, some additional `Suggests` *MAY* be used by overwriting `+%{__R_whitelist}+` as follows:
-
-----
-%global __R_whitelist testthat|mockery|withr
-----
-
-if the packager wishes to use `mockery` and `withr` on top of `testthat`.
-
-=== Building and Installing
-
-R packages are built and installed in a single stage via `R CMD INSTALL`.
-Therefore, the `+%build+` section *MUST* be empty.
-
-Two macros are provided and *MUST* be called in the `+%install+` section.
-First, `+%R_install+` builds and installs the package into `+%{buildroot}%{_R_libdir}+`,
-then `+%R_save_files+` generates a list of files corresponding to the given importable module, and saves it as `+%{R_files}+`.
-
-----
-%build
-
-%install
-%R_install
-%R_save_files
-----
-
-[NOTE]
-====
-The `+%R_install+` macro ensures reprodubility by setting the package's build timestamp as `$SOURCE_DATE_EPOCH`.
-====
-
-[NOTE]
-====
-R package installation generates a new `R.css` file that conflicts with the master `R.css` file included in the main R package.
-The `+%R_install+` macro deletes this file.
-====
-
-[NOTE]
-====
-The `+%R_install+` macro calls `+%_R_libdir_check+` to ensure that a noarch package did not produce a shared library,
-or an archful package actually contains a shared library;
-otherwise, it fails with an informative error message.
-If the packager does not want this check, `+%_R_libdir_check+` *MAY* be set to `+%nil+`.
-====
-
-=== Testing
-
-The `+%R_check+` macro *MUST* be called in the `+%check+` section to run R package checks.
-
-----
-%check
-%R_check
-----
-
-According to CRAN’s guidelines, R packages *MUST* work without soft dependencies.
-If package checks fail because soft dependencies are used unconditionally (e.g. in examples or tests), this is considered a bug and *SHOULD* be reported upstream.
-Meanwhile, a workaround *MUST* be put in place:
-
-* If the failure happens in an example, the `\--no-examples` flag *MAY* be appended to `+%R_check+`.
-* If the failure happens in a test, a `skip()` call *MAY* be added in the proper place to skip a test,
-or a test file *MAY* be removed,
-or even the `\--no-tests` flag *MAY* be appended to `+%R_check+` for more complicated situations.
-
-=== Listing files
-
-Module files *MUST* be added via the `-f` option as follows:
-
-----
-%files -f %{R_files}
-----
-
-If necessary, any additional files outside the package's path *SHOULD* be added explicitly afterwards.
-
-== Example spec file
-
-This is an example spec file for a hypothetical R package called "foo", with upstream version `1.2-3`:
-
-----
-Name:           R-foo
-Version:        %R_rpm_version 1.2-3
-Release:        %autorelease
-Summary:        Adds foo functionality for R
-
-License:        GPL-2.0-or-later
-URL:            %{cran_url}
-Source:         %{cran_source}
-
-# BuildArch:      noarch
-BuildRequires:  R-devel
-# BuildRequires:  somelib-devel
-
-%description
-R Interface to foo, enables bar!
-
-%prep
-%autosetup -c
-
-%generate_buildrequires
-%R_buildrequires
-
-%build
-
-%install
-%R_install
-%R_save_files
-
-%check
-%R_check
-
-%files -f %{R_files}
-
-%changelog
-%autochangelog
-----
diff --git a/guidelines/modules/ROOT/pages/RPMMacros.adoc b/guidelines/modules/ROOT/pages/RPMMacros.adoc
deleted file mode 100644
index 65293ef..0000000
--- a/guidelines/modules/ROOT/pages/RPMMacros.adoc
+++ /dev/null
@@ -1,140 +0,0 @@
-:last-reviewed: 2019-02-14
-:build-flags: link:https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md[build flags documentation]
-
-= RPM Macros
-
-RPM provides a rich set of macros
-to make package maintenance simpler and consistent across packages.
-For example, it includes a list of default path definitions
-which are used by the build system macros,
-and definitions for RPM package build specific directories.
-They usually should be used instead of hard-coded directories.
-It also provides the default set of compiler flags as macros,
-which should be used when compiling manually and not relying on a build system.
-
-
-== Getting and setting Macros on the command line
-
-It's possible to let RPM evaluate arbitrary strings containing macros
-on the command line by running `rpm --eval` on the command line:
-
-....
-$ rpm --eval "some text printed on %{_arch}"
-some text printed on x86_64
-....
-
-Additionally, values for macros can be temporarily provided (and overridden)
-by providing command line options to `rpm` and `rpmbuild`:
-
-....
-$ rpm --define "test Hello, World!" --eval "%{test}"
-Hello, World!
-....
-
-[#macros_installation]
-== Macros for paths set and used by build systems
-
-The macros for build system invocations
-(for example, `%configure`, `%cmake`, or `%meson`)
-use the values defined by RPM to set installation paths for packages.
-So, it's usually preferable to not hard-code these paths in spec files either,
-but use the same macros for consistency.
-
-The values for these macros can be inspected
-by looking at `/usr/lib/rpm/platform/*/macros` for the respective platform.
-
-The following table lists macros which are widely used in fedora `.spec` files.
-
-[cols="32%m,28%m,40%",options="header"]
-|=================================
-| macro                | definition                  | comment
-| +%{_sysconfdir}+     | /etc                        |
-| +%{_prefix}+         | /usr                        | can be defined to `/app` for flatpak builds
-| +%{_exec_prefix}+    | +%{_prefix}+                | default: `/usr`
-| +%{_includedir}+     | +%{_prefix}+/include        | default: `/usr/include`
-| +%{_bindir}+         | +%{_exec_prefix}+/bin       | default: `/usr/bin`
-| +%{_libdir}+         | +%{_exec_prefix}/%{_lib}+   | default: `+/usr/%{_lib}+`
-| +%{_libexecdir}+     | +%{_exec_prefix}+/libexec   | default: `/usr/libexec`
-| +%{_datadir}+        | +%{_datarootdir}+           | default: `/usr/share`
-| +%{_infodir}+        | +%{_datarootdir}+/info      | default: `/usr/share/info`
-| +%{_mandir}+         | +%{_datarootdir}+/man       | default: `/usr/share/man`
-| +%{_docdir}+         | +%{_datadir}+/doc           | default: `/usr/share/doc`
-| +%{_rundir}+         | /run                        |
-| +%{_localstatedir}+  | /var                        |
-| +%{_sharedstatedir}+ | /var/lib                    |
-| +%{_lib}+            | lib64                       | `lib` on 32bit platforms
-|=================================
-
-Some seldomly used macros are listed below for completeness.
-Old `.spec` files might still use them,
-and there might be cases where they are still needed.
-
-[cols="32%m,28%m,40%",options="header"]
-|=================================
-| macro                | definition                   | comment
-| +%{_datarootdir}+    | +%{_prefix}/share+           | default: `/usr/share`
-| +%{_var}+            | /var                         |
-| +%{_sbindir}+        | same as +%{_bindir}+         | historically `/usr/sbin`, now `/usr/bin`, provided for compatibility
-| +%{_tmppath}+        | +%{_var}/tmp+                | default: `/var/tmp`
-| +%{_usr}+            | /usr                         |
-| +%{_usrsrc}+         | +%{_usr}/src+                | default: `/usr/src`
-| +%{_initddir}+       | +%{_sysconfdir}/rc.d/init.d+ | default: `/etc/rc.d/init.d`
-| +%{_initrddir}+      | +%{_initddir}+               | old misspelling, provided for compatiblity
-|=================================
-
-
-== Macros set for the RPM (and SRPM) build process
-
-RPM also exposes the locations of several directories
-that are relevant to the package build process via macros.
-
-The only macro that's widely used in `.spec` files is `+%{buildroot}+`,
-which points to the root of the installation target directory.
-It is used for setting `DESTDIR` in the package's `%install` step.
-
-The other macros are usually only used outside `.spec` files.
-For example, they are set by `fedpkg` to override the default directories.
-
-[cols="25%m,60%m,15%",options="header"]
-|=================================
-| macro                | definition                   | comment
-| +%{buildroot}+       | +%{_buildrootdir}/%{name}-%{version}-%{release}.%{_arch}+ | same as `$BUILDROOT`
-| +%{_topdir}+         | +%{getenv:HOME}/rpmbuild+    |
-| +%{_builddir}+       | +%{_topdir}/BUILD+           |
-| +%{_rpmdir}+         | +%{_topdir}/RPMS+            |
-| +%{_sourcedir}+      | +%{_topdir}/SOURCES+         |
-| +%{_specdir}+        | +%{_topdir}/SPECS+           |
-| +%{_srcrpmdir}+      | +%{_topdir}/SRPMS+           |
-| +%{_buildrootdir}+   | +%{_topdir}/BUILDROOT+       |
-|=================================
-
-
-== Macros providing compiler and linker flags
-
-The default build flags for binaries on fedora are available via macros.
-They are used by the build system macros to setup the build environment,
-so it is usually not necessary to use them directly --
-except, for example, when doing bare bones compilation with `gcc` directly.
-
-The set of flags listed below reflects the current state of fedora 42
-on a `x86_64` machine, as defined in the file `/usr/lib/rpm/redhat/macros`.
-
-The `+%{optflags}+` macro contains flags that determine `CFLAGS`, `CXXFLAGS`,
-`FFLAGS`, etc.
-
-The current definitions of these values
-can be found in the `redhat-rpm-config` package, in the {build-flags}.
-
-....
-$ rpm --eval "%{optflags}"
--O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-....
-
-The value of the `LDFLAGS` environment variable set by build systems
-is determined by the `+%{build_ldflags}+` macro:
-
-....
-$ rpm -E "%{build_ldflags}"
--Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
-....
-
diff --git a/guidelines/modules/ROOT/pages/RPM_Source_Dir.adoc b/guidelines/modules/ROOT/pages/RPM_Source_Dir.adoc
deleted file mode 100644
index 8942283..0000000
--- a/guidelines/modules/ROOT/pages/RPM_Source_Dir.adoc
+++ /dev/null
@@ -1,59 +0,0 @@
-= `+$RPM_SOURCE_DIR+` or `+%{_sourcedir}+`
-
-Packages which use files itemized as `+Source#+` files,
-must refer to those files by their `+%{SOURCE#}+` macro name,
-and must not use `+$RPM_SOURCE_DIR+` or `+%{_sourcedir}+` to refer to those files.
-
-This is done to ensure that Fedora SRPMS are properly generated.
-If a `+Source#+` item is renamed,
-a spec which refers to its old name may succeed locally
-(because the file is still in `+%{_sourcedir}+` along with the new file),
-but the proper file will not be included in the SRPM.
-
-*Incorrect Use:*
-
-....
-Source: php.conf
-Source: php.ini
-Source: macros.php
-
-...
-
-install -m 644 $RPM_SOURCE_DIR/php.conf $RPM_BUILD_ROOT/etc/httpd/conf.d
-sed -e "s/@PHP_APIVER@/%{apiver}/;s/@PHP_ZENDVER@/%{zendver}/;s/@PHP_PDOVER@/%{pdover}/" \
-    < $RPM_SOURCE_DIR/macros.php > macros.php
-....
-
-*Correct Use:*
-
-....
-Source1: php.conf
-Source2: php.ini
-Source3: macros.php
-
-...
-
-install -m 644 %{SOURCE1} $RPM_BUILD_ROOT/etc/httpd/conf.d
-sed -e "s/@PHP_APIVER@/%{apiver}/;s/@PHP_ZENDVER@/%{zendver}/;s/@PHP_PDOVER@/%{pdover}/" \
-    < %{SOURCE3} > macros.php
-....
-
-== Exceptions
-
-When there is an available list of supplementary source files,
-it is permissible to use this list in conjunction with `+%{_sourcedir}+`
-to simplify operations on those supplementary source files.
-
-An example of this from the kde-l10n package:
-
-....
-for i in $(cat %{SOURCE1000}) ; do
-  echo $i | grep -v '^#' && \
-  bzip2 -dc %{_sourcedir}/%{name}-$i-%{version}.tar.bz2 | tar -xf -
-done
-....
-
-where `+Source1000: subdirs-kde-l10n+` is a list provided by upstream of all the languages supported,
-and there are ~50 `+SourceN:+` tags, which can vary from version from version,
-but match the languages listed in `+Source1000+`,
-for the tarballs provided by upstream.
diff --git a/guidelines/modules/ROOT/pages/ReviewGuidelines.adoc b/guidelines/modules/ROOT/pages/ReviewGuidelines.adoc
deleted file mode 100644
index cce194c..0000000
--- a/guidelines/modules/ROOT/pages/ReviewGuidelines.adoc
+++ /dev/null
@@ -1,299 +0,0 @@
-= Package Review Guidelines
-
-This is a set of guidelines for Package Reviews.
-Note that a complete list of things to check for would be impossible,
-but every attempt has been made
-to make this document as comprehensive as possible.
-Reviewers and contributors (packagers)
-should use their best judgement
-whenever items are unclear,
-and if in doubt,
-ask on the https://lists.fedoraproject.org/admin/lists/packaging.lists.fedoraproject.org/[Fedora packaging list] .
-
-== Package Review Guidelines
-
-Contributors and reviewers
-MUST follow the https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/[Package Review Process],
-with the exceptions listed in the next section
-
-== Package Review Exceptions
-
-The following exceptions apply to the review process linked above
-
-* FPC grants an explicit exemption from the process,
-  as indicated https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure[here].
-* The package is being created
-  so that multiple versions of the same package can coexist in the distribution
-  (or coexist between EPEL and RHEL).
-  The package MUST be properly named
-  according to the xref:Naming.adoc#_multiple_packages_with_the_same_base_name[naming guidelines]
-  and MUST NOT conflict with all other versions of the same package.
-* The package exists in both Fedora and RHEL,
-  but the packager wants to ship it in EPEL
-  under an alternative name
-  (as required by https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy[EPEL policy])
-  to provide a subpackage that exists in Fedora
-  but does not exist (or is not shipped) in RHEL.
-
-.Exemptions which have been explicitly granted:
-
-* fXX-backgrounds
-(https://pagure.io/packaging-committee/issue/1479[ticket]):
-This package doesn't follow the usual naming conventions
-for versioned packages,
-but a new one is created per Fedora release.
-
-== Relaxed rules for existing components
-
-Some guidelines that apply to "new" packages
-do not need to be applied when reviewing packages
-that are only _"added"_ to the distribution
-in the sense that the name of the _source package_ is "new"
-but the component was already available
-from an existing package, i.e. when
-
-* renaming an existing package,
-* moving a subcomponent from an existing package
-  into a separate source package,
-* adding an alternative version ("compat package")
-  of an existing package, or
-* adding an EPEL-only alternative version
-  of an existing package.
-
-For example, it is allowed for a _"new"_ package like this
-to depend on packages marked as `+deprecated()+`
-because no _actually new_ component
-will depend on the deprecated package.
-
-== Things To Check On Review
-
-There are many many things to check for a review.
-This list is provided to assist new reviewers
-in identifying areas that they should look for,
-but is by no means complete.
-Reviewers should use their own good judgement
-when reviewing packages.
-The items listed fall into two categories:
-*SHOULD* and *MUST*.
-
-* [[rpmlint]] *MUST*:
-  rpmlint must be run on the source rpm and all binary rpms the build produces.
-  The output should be posted in the review.
-  See xref:index.adoc#_use_rpmlint[Packaging Guidelines: Use rpmlint].
-* [[naming]] *MUST*:
-  The package must be named according to the xref:Naming.adoc[Package Naming Guidelines].
-* [[spec-fie-name]] *MUST*:
-  The spec file name must match the base package `+%{name}+`,
-  in the format `+%{name}.spec+`
-  unless your package has an exemption.
-  See xref:index.adoc#_spec_file_naming[Packaging Guidelines: Spec File Naming].
-* [[packaging-guidelines]] *MUST*:
-  The package must meet the xref:index.adoc[Packaging Guidelines].
-* [[approved-license]] *MUST*:
-  The package must be licensed with a Fedora approved license
-  and meet the xref:LicensingGuidelines.adoc[Licensing Guidelines].
-* [[license-field]] *MUST*:
-  The License field in the package spec file
-  must match the actual license.
-  See xref:LicensingGuidelines.adoc#_valid_license_short_names[Licensing Guidelines: Valid License Short Names].
-* [[license-file]] *MUST*:
-  If (and only if) the source package includes the text of the license(s) in its own file,
-  then that file, containing the text of the license(s) for the package
-  must be included in `+%license+`.
-  See xref:LicensingGuidelines.adoc#_license_text[Licensing Guidelines: License Text].
-* [[spec-in-american-english]] *MUST*:
-  The spec file must be written in American English.
-  See xref:index.adoc#_summary_and_description[Packaging Guidelines: Summary and description].
-* [[legible-spec]] *MUST*:
-  The spec file for the package *MUST* be legible.
-  See xref:index.adoc#_spec_legibility[Packaging Guidelines: Spec Legibility].
-* [[build-sources]] *MUST*:
-  The sources used to build the package
-  must match the upstream source,
-  as provided in the spec URL.
-  Reviewers should use sha256sum for this task
-  as it is used by the `+sources+` file once imported into git.
-  If no upstream URL can be specified for this package,
-  please see the xref:SourceURL.adoc[Source URL Guidelines] for how to deal with this.
-* [[successful-build]] *MUST*:
-  The package *MUST* successfully compile and build into binary rpms
-  on at least one primary architecture.
-  See xref:index.adoc#_architecture_support[Packaging Guidelines: Architecture Support].
-* [[exclude-arch]] *MUST*:
-  If the package does not successfully compile,
-  build or work on an architecture,
-  then those architectures should be listed in the spec in `+ExcludeArch+`.
-  Each architecture listed in `+ExcludeArch+` *MUST* have a bug filed in bugzilla,
-  describing the reason that the package does not compile/build/work on that architecture.
-  The bug number *MUST* be placed in a comment,
-  next to the corresponding `+ExcludeArch+` line.
-  See xref:index.adoc#_architecture_build_failures[Packaging Guidelines: Architecture Build Failures].
-* [[build-dependencies]] *MUST*:
-  All build dependencies must be listed in `+BuildRequires+`.
-  See xref:index.adoc#buildrequires[Packaging Guidelines: Build-Time Dependencies (BuildRequires)].
-* [[locales]] *MUST*:
-  The spec file MUST handle locales properly.
-  This is done by using the `+%find_lang+` macro.
-  Using `+%{_datadir}/locale/*+` is strictly forbidden.
-  See xref:index.adoc#_handling_locale_files[Packaging Guidelines: Handling Locale Files].
-* [[bundling]] *MUST*:
-  Packages must NOT bundle copies of system libraries.
-  See xref:index.adoc#bundling[Packaging Guidelines: Bundling and Duplication of System Libraries].
-* [[relocatable-package]] *MUST*:
-  If the package is designed to be relocatable,
-  the packager must state this fact in the request for review,
-  along with the rationalization for relocation of that specific package.
-  Without this, use of Prefix: /usr is considered a blocker.
-  See xref:index.adoc#_relocatable_packages[Packaging Guidelines: Relocatable Packages].
-* [[directory-ownership]] *MUST*:
-  A package must own all directories that it creates.
-  If it does not create a directory that it uses,
-  then it should require a package
-  which does create that directory.
-  See xref:index.adoc#_file_and_directory_ownership[Packaging Guidelines: File And Directory Ownership].
-* [[file-listed-once]] *MUST*:
-  A Fedora package must not list a file more than once
-  in the spec file's %files listings.
-  (Notable exception: license texts in specific situations)See xref:index.adoc#_duplicate_files[Packaging Guidelines: Duplicate Files].
-* [[premissions]] *MUST*:
-  Permissions on files must be set properly.
-  Executables should be set with executable permissions, for example.
-  See xref:index.adoc#_file_permissions[Packaging Guidelines: File Permissions].
-* [[consistent-macros]] *MUST*:
-  Each package must consistently use macros.
-  See xref:index.adoc#_macros[Packaging Guidelines: Macros].
-* [[permisible-content]] *MUST*:
-  The package must contain code,
-  or permissible content.
-  See xref:what-can-be-packaged.adoc[What Can Be Packaged].
-* [[large-documentation]] *MUST*:
-  Large documentation files must go in a -doc subpackage.
-  (The definition of large is left up to the packager's best judgement,
-  but is not restricted to size.
-  Large can refer to either size or quantity).
-  See xref:index.adoc#_documentation[Packaging Guidelines: Documentation].
-* [[doc-runtime]] *MUST*:
-  If a package includes something as %doc,
-  it must not affect the runtime of the application.
-  To summarize: If it is in %doc,
-  the program must run properly if it is not present.
-  See xref:index.adoc#_documentation[Packaging Guidelines: Documentation].
-* [[static-libraries]] *MUST*:
-  Static libraries must be in a -static package.
-  See xref:index.adoc#packaging-static-libraries[Packaging Guidelines: Packaging Static Libraries].
-* [[devel-subpackage]] *MUST*:
-  Development files must be in a -devel package.
-  See xref:index.adoc#_devel_packages[Packaging Guidelines: Devel Packages].
-* [[versioned-devel-require]] *MUST*:
-  In the vast majority of cases,
-  devel packages must require the base package
-  using a fully versioned dependency:
-  `+Requires: %{name}%{?_isa} = %{version}-%{release}+`.
-  See xref:index.adoc#_requiring_base_package[Packaging Guidelines: Requiring Base Package].
-* [[la-archives]] *MUST*:
-  Packages must NOT contain any .la libtool archives,
-  these must be removed in the spec if they are built.
-  See xref:index.adoc#packaging-static-libraries[Packaging Guidelines: Packaging Static Libraries].
-* [[desktop-file]] *MUST*:
-  Packages containing GUI applications must include a %\{name}.desktop file,
-  and that file must be properly installed
-  with `desktop-file-install` in the `+%install+` section.
-  If you feel that your packaged GUI application
-  does not need a .desktop file,
-  you must put a comment in the spec file
-  with your explanation.
-  See xref:index.adoc#_desktop_files[Packaging Guidelines: Desktop files].
-* [[file-directory-ownership]] *MUST*:
-  Packages must not own files or directories
-  that are already owned by other packages.
-  The rule of thumb here is
-  that the first package to be installed
-  should own the files or directories
-  that other packages may rely upon.
-  This means, for example,
-  that no package in Fedora should ever share ownership
-  with any of the files or directories
-  owned by the `+filesystem+` or `+man+` package.
-  If you feel that you have a good reason
-  to own a file or directory that another package owns,
-  then please present that at package review time.
-  See xref:index.adoc#_file_and_directory_ownership[Packaging Guidelines: File and Directory Ownership].
-* [[utf-8]] *MUST*:
-  All filenames in rpm packages must be valid UTF-8.
-  See xref:index.adoc#_non_ascii_filenames[Packaging Guidelines: Non-ASCII Filenames].
-* [[deprecated-packages]] *MUST*:
-  Packages being added to the distribution
-  MUST NOT depend on any packages
-  which have been marked as being deprecated.
-  See xref:deprecating-packages.adoc[Deprecating Packages].
-
-'''
-
-* [[upstream-license-file]] *SHOULD*:
-  If the source package does not include license text(s)
-  as a separate file from upstream,
-  the packager SHOULD query upstream to include it.
-  See xref:LicensingGuidelines.adoc#_license_text[Licensing Guidelines: License Text].
-* [[builds-in-mock]] *SHOULD*:
-  The reviewer should test that the package builds in mock.
-  See https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds[Using Mock to test package builds].
-* [[supports-all-architectures]] *SHOULD*:
-  The package should compile and build into binary rpms
-  on all supported architectures.
-  See xref:index.adoc#_architecture_support[Packaging Guidelines: Architecture Support].
-* [[symbols-are-versioned]] *SHOULD*:
-  Shared libraries should provide versioned symbols (as in "libc.so.6(*GLIBC_2.41*)(64bit)".
-  Maintainers are encouraged to work with upstream projects that do not yet provide
-  versioned symbols to add them.
-  See xref:C_and_C++.adoc[Versioned Symbols]
-* [[functions-as-described]] *SHOULD*:
-  The reviewer should test that the package functions as described.
-  A package should not segfault instead of running, for example.
-* [[sane-scriplets]] *SHOULD*:
-  If scriptlets are used, those scriptlets must be sane.
-  This is vague, and left up to the reviewers judgement to determine sanity.
-  See xref:index.adoc#_scriptlets[Packaging Guidelines: Scriptlets].
-* [[subpackage-versioned-requires]] *SHOULD*:
-  Usually, subpackages other than devel should require the base package
-  using a fully versioned dependency.
-  See xref:index.adoc#_requiring_base_package[Packaging Guidelines: Requiring Base Package].
-* [[pkgconfig-in-devel]] *SHOULD*:
-  The placement of pkgconfig(.pc) files depends on their usecase,
-  and this is usually for development purposes,
-  so should be placed in a -devel pkg.
-  A reasonable exception is that the main pkg itself
-  is a devel tool not installed in a user runtime,
-  e.g. gcc or gdb.
-  See xref:index.adoc#_pkgconfig_files_foo_pc[Packaging Guidelines: Pkgconfig Files].
-* [[man-pages]] *SHOULD*:
-  Your package should contain man pages for binaries/scripts.
-  If it doesn't, work with upstream to add them where they make sense.
-  See xref:index.adoc#_manpages[Packaging Guidelines: Manpages].
-
-== A note on dependencies
-
-It is often useful to submit a package for review
-along with its dependencies in separate tickets.
-As long as the submitter sets up the _Depends on:_ and _Blocks:_ fields in BugZilla properly,
-this is not an issue,
-and it is perfectly possible to review these packages
-before the full dependency chain is in the distribution
-(by maintaining a local repository,
-building and installing the packages locally,
-or maintaining a COPR).
-
-However, please keep in mind that you cannot do koji builds
-unless all of the build dependencies are met
-(because you cannot provide additional dependencies to koji)
-and when the time comes to build these packages,
-they must be built in order
-and you must wait between builds for the dependencies
-to make it into the appropriate branch of the distribution.
-This can be automated using side tags and chain builds.
-
-Please also note that while you may actually be able to build a package
-because all of its build-time dependencies are met,
-the package may still be non-installable (and thus useless)
-if its _runtime_ dependencies are not met.
-A package *MUST* not be built
-if any of its runtime dependencies are unsatisfied.
diff --git a/guidelines/modules/ROOT/pages/Ruby.adoc b/guidelines/modules/ROOT/pages/Ruby.adoc
deleted file mode 100644
index 2f3a5a0..0000000
--- a/guidelines/modules/ROOT/pages/Ruby.adoc
+++ /dev/null
@@ -1,560 +0,0 @@
-= Ruby Packaging Guidelines
-
-NOTE: *JRuby Gems*:
-Although Fedora has fully functioning JRuby
-integrated with system RubyGems,
-we have decided to not include the JRuby specific packaging guidelines here,
-as they need some more work.
-They will appear here as soon as we feel that we've got everything covered properly.
-You can contact us on
-https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/[Ruby-SIG mailing list]
-in case of any questions
-about the prepared JRuby packaging guidelines.
-
-There are three basic categories of ruby packages:
-<<RubyGems>>,
-<<Non-Gem Packages,non-gem Ruby packages>>,
-and <<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.
-
-== Ruby Compatibility
-
-Each Ruby package MUST indicate it depends on a Ruby interpreter
-(this does not apply to <<RubyGems>>).
-Use `ruby(release)` virtual requirement to achieve that:
-
-....
-Requires: ruby(release)
-....
-
-If the package requires Ruby of certain version(s),
-make the requirement versioned like this:
-
-....
-Requires: ruby(release) >= 1.9.1
-....
-
-NOTE: *Alternate interpreters*:
-Alternate Ruby interpreters (currently JRuby)
-also `Provide: ruby(release)`.
-This implies, that pure RubyGems packages (these are shared among interpreters) SHOULD NOT have `Requires: ruby` or `Requires: jruby` to have their dependencies satisfied by any of these interpreters.
-
-WARNING: *Over specified ruby(release) versioning*:
-Please note that if the `ruby(release)` version requirement is too specific,
-it might cause an unexpected interpreter to be drawn in.
-E.g. `ruby(release) = 1.8` will require JRuby package,
-since it is the only package that provides it.
-
-=== Different Interpreters Compatibility
-
-Most of the pure Ruby packages will work on all Ruby interpreters.
-There are however cases when the packages use interpreter-specific functions
-(like `fork()`)
-and won't run on other interpreters (JRuby).
-In this case, the package SHOULD require that interpreter.
-For example, a package that uses `fork` SHOULD explicitly specify `Requires: ruby`.
-In case of such package,
-packager SHOULD file a bug to ask upstream
-to provide support for other interpreter(s).
-This SHOULD be documented in specfile.
-
-=== Shebang lines
-
-On Fedora,
-`/usr/bin/ruby` is implemented via https://github.com/bkabrda/rubypick[Rubypick].
-Rubypick is a tool similar to RVM or rbenv.
-It allows choosing interpreter to execute Ruby script.
-Rubypick routes anything executed via
-`/usr/bin/ruby`
-to `/usr/bin/ruby-mri`
-or `/usr/bin/jruby`.
-By default, it runs MRI (Matz's Ruby Implementation),
-but user can explicitly specify the interpreter by using
-`+_mri_+`
-or `+_jruby_+`
-as a first parameter.
-For example:
-
-....
-ruby _jruby_ jruby_script.rb
-gem _mri_ install foo
-rails _jruby_ s
-....
-
-Using the `RUBYPICK` environment variable can achieve the same results.
-The environment variable can be used
-to set one interpreter as the global default:
-
-....
-export RUBYPICK=_jruby_
-ruby jruby_script.rb  # Will use jruby
-gem install foo        # Will also use jruby
-....
-
-Ruby executables that are known
-to only run on one Ruby implementation
-SHOULD use that specific implementation in their shebang
-(`+#!/usr/bin/ruby-mri+` or `+#!/usr/bin/jruby+`)
-to ensure that they run using that implementation.
-All other code SHOULD use `+#!/usr/bin/ruby+`.
-
-== Naming Guidelines
-
-* Packages that contain Ruby Gems MUST be called
-  `+rubygem-%{gem_name}+`.
-
-* The name of a ruby extension/library package MUST start
-  with the interpreter it is built for
-  (ruby, jruby, etc.)
-  and then the `UPSTREAM` name.
-  For example: `ruby-UPSTREAM`.
-  If the upstream name `UPSTREAM` contains `ruby`,
-  that SHOULD be dropped from the name.
-  For example, the SQLite database driver for ruby is called `sqlite3-ruby`.
-  The corresponding Fedora package SHOULD be called `ruby-sqlite3`,
-  and not `ruby-sqlite3-ruby`.
-
-* Application packages that mainly provide user-level tools
-  that happen to be written in Ruby MUST follow
-  the general xref:Naming.adoc[Naming Guidelines] instead.
-
-== Macros
-
-Non-gem ruby packages and ruby gem packages
-install to certain standard locations.
-The `ruby-devel` and `rubygems-devel` packages
-contain macros useful for the respective package types.
-Alternate ruby interpreters will have equivalent locations
-(to be added to this table later).
-
-[%header,cols="1,2,1"]
-|===
-|Macro
-|Expanded path
-|Usage
-
-3+|*From ruby-devel; intended for non-gem packages.*
-
-|`+%{ruby_vendorarchdir}+`
-|`+/usr/lib{64}/ruby/vendor_ruby+`
-|Place for architecture specific (e.g. *.so) files.
-
-|`+%{ruby_vendorlibdir}+`
-|`+/usr/share/ruby/vendor_ruby+`
-|Place for architecture independent (e.g. *.rb) files.
-
-|`+%{ruby_sitearchdir}+`
-|`+/usr/local/lib{64}/ruby/site_ruby+`
-|Place for local architecture specific (e.g. *.so) files.
-
-|`+%{ruby_sitelibdir}+`
-|`+/usr/local/share/ruby/site_ruby+`
-|Place for local architecture independent (e.g. *.rb) files.
-
-3+|*From rubygems-devel; intended for gem packages.*
-
-|`+%{gem_dir}+`
-|`+/usr/share/gems+`
-|Top directory for the Gem structure.
-
-|`+%{gem_instdir}+`
-|`+%{gem_dir}/gems/%{gem_name}-%{version}+`
-|Directory with the actual content of the Gem.
-
-|`+%{gem_libdir}+`
-|`+%{gem_instdir}/lib+`
-|The `lib` folder of the Gem.
-
-|`+%{gem_cache}+`
-|`+%{gem_dir}/cache/%{gem_name}-%{version}.gem+`
-|The cached Gem.
-
-|`+%{gem_spec}+`
-|`+%{gem_dir}/specifications/%{gem_name}-%{version}.gemspec+`
-|The Gem specification file.
-
-|`+%{gem_docdir}+`
-|`+%{gem_dir}/doc/%{gem_name}-%{version}+`
-|The rdoc documentation of the Gem.
-
-|`+%{gem_extdir_mri}+`
-|`+%{_libdir}/gems/ruby/%{gem_name}-%{version}+`
-|The directory for MRI Ruby Gem extensions.
-
-|===
-
-=== Interpreter independence and directory macros
-
-You might have noticed that the table above
-has different directories for non-gem libraries
-on different ruby interpreters
-but only a single set of directories for rubygem libraries.
-This is because code written for one ruby interpreter
-will often run on all ruby interpreters that Fedora ships
-(ruby, jruby, etc.).
-However, some code uses methods
-that are not available on all interpreters
-(see <<Different Interpreters Compatibility>>).
-Rubygems have a facility to ship different versions
-of the code in the same gem
-so that the gem can run on all versions
-of the interpreter,
-so we only need to have one common directory for rubygems
-that all the interpreters can use.
-
-The standard ruby `+%{vendorlib}+` directories lack this facility.
-For this reason, non-gem libraries need to be placed
-in per-interpreter directories
-and MUST have a separate subpackage
-(or package depending on upstream)
-for each interpreter that they support.
-
-== Libraries
-
-These guidelines only apply to Ruby packages
-whose main purpose is providing a Ruby library;
-packages that mainly provide user-level tools
-that happen to be written in Ruby
-MUST follow the <<Applications,Ruby applications Guidelines>> instead.
-
-=== RubyGems
-
-https://rubygems.org/[RubyGems] are Ruby's own packaging format.
-Gems contain a lot of the same metadata that RPM's need,
-making fairly smooth interoperation between RPM and Gems possible.
-This guideline ensures that Gems are packaged as RPMs
-in a way that such RPMs fit cleanly with the rest of the distribution
-and makes it possible for the end user
-to satisfy dependencies of a Gem
-by installing the appropriate RPM-packaged Gem.
-
-Both RPM's and Gems use similar terminology;
-there are specfiles,
-package names,
-dependencies, etc.
-for both.
-To keep confusion to a minimum,
-terms relating to Gem concepts will be explicitly referred to
-with the word "Gem" prefixed,
-e.g., "Gem specification" (.gemspec).
-An unqualified "package" in the following always means an RPM.
-
-* Spec files MUST contain a definition of `+%{gem_name}+`
-  which is the name from the Gem's specification.
-
-* The `Source` of the package SHOULD be
-  the full URL to the released Gem archive;
-  otherwise, the spec file MUST contain a comment
-  explaining why a different `Source` was chosen.
-
-* The version of the package MUST be the Gem's version.
-
-* The package MUST have
-  `BuildRequires: rubygems-devel`
-  to pull in the macros needed to build.
-
-* There SHOULD NOT be any rubygem `Requires` nor `Provides` listed,
-  since those are autogenerated.
-
-* There SHOULD NOT be `Requires: ruby(release)`,
-  unless you want to explicitly specify Ruby version compatibility.
-  The automatically generated dependency on RubyGems
-  (`Requires: ruby(rubygems)`)
-  is enough.
-
-==== Filtering Requires and Provides
-
-Runtime requires and provides are automatically generated
-by RPM's dependency generator.
-However, it can sometimes throw in additional dependencies contrary to reality.
-To fix this, the dependency generator needs to be overridden
-so that the additional dependencies can be filtered out.
-See xref:AutoProvidesAndRequiresFiltering.adoc[AutoProvidesAndRequiresFiltering] for details.
-
-==== Building gems
-
-Since gems aren't just an archive format
-but instead encapsulate both an archive
-and information used for building the Ruby library,
-building an RPM from a gem looks a little different
-from other RPMs.
-
-A sample spec for building gems would look like this:
-
-....
-%prep
-%autosetup -p1 -n  %{gem_name}-%{version}
-
-# Modify the gemspec if necessary
-
-%build
-# Create the gem as gem install only works on a gem file
-gem build ../%{gem_name}-%{version}.gemspec
-
-# %%gem_install compiles any C extensions and installs the gem into ./%%gem_dir
-# by default, so that we can move it into the buildroot in %%install
-%gem_install
-
-%install
-mkdir -p %{buildroot}%{gem_dir}
-cp -a ./%{gem_dir}/* %{buildroot}%{gem_dir}/
-
-# If there were programs installed:
-mkdir -p %{buildroot}%{_bindir}
-cp -a ./%{_bindir}/* %{buildroot}%{_bindir}
-
-# If there are C extensions, copy them to the extdir.
-mkdir -p %{buildroot}%{gem_extdir_mri}
-cp -a .%{gem_extdir_mri}/{gem.build_complete,*.so} %{buildroot}%{gem_extdir_mri}/
-....
-
-===== %prep
-
-RPM (as of 4.14) can directly unpack gem archives, so we can call `gem unpack` to extract the source from the gem. Then we call `+%setup -n %{gem_name}-%{version}+` to tell rpm what the directory the gem has unpacked into. At the same directory level, the %\{gem_name}-%\{version}.gemspec file is created automatically as well. This `.gemspec` file will be used to rebuild the gem later. If we need to modify the `.gemspec` (for instance, if the version of dependencies is wrong for Fedora or the `.gemspec` is using old, no longer supported fields) we would do it here. Patches to the code itself can also be done here.
-
-===== %build
-
-Next we build the gem. Because `+%gem_install+` only operates on gem archives, we next recreate the gem with `gem build`. The gem file that is created is then used by `+%gem_install+` to build and install the code into the temporary directory, which is `+./%{gem_dir}+` by default. We do this because the `+%gem_install+` command both builds and installs the code in one step so we need to have a temporary directory to place the built sources before installing them in `+%install+` section.
-
-`+%gem_install+` macro accepts two additional options:
-
--n <gem_file>::
-  Allows to override gem used for installation. This might get useful for converting legacy spec, so you might specify %\{SOURCE0} as a gem for installation.
--d <install_dir>::
-  Might override the gem installation destination. However we do not suggest to use this option.
-
-NOTE: The `+%gem_install+` macro MUST NOT be used to install into the `+%{buildroot}+`
-
-===== %install
-
-Here we actually install into the `+%{buildroot}+`. We create the directories that we need and then copy what was installed into the temporary directories into the `+%{buildroot}+` hierarchy. Finally, if this ruby gem creates shared objects the shared objects are moved into the arch specific `+%{gem_extdir_mri}+` path.
-
-==== Patching required gem versions
-
-One common patching need is to change overly strict version requirements in the upstream `.gemspec`. This could be because upstream's `.gemspec` only mentions versions that they've explicitly tested against but we know that a different version will also work or because we know that the packages we ship have applied fixes for problematic behavior without bumping the version number (for instance, backported fixes). To adjust such dependencies, you can use the `+%gemspec_add_dep+` and `+%gemspec_remove_dep+` macros.
-
-For example, if you wanted to use any version of Aruba instead of the overly specific version requested by upstream, you could use in `+%prep+` section following two lines:
-
-....
-%gemspec_remove_dep -g aruba "~> 0.14.2"
-%gemspec_add_dep -g aruba
-....
-
-CAUTION: *Use macros only on top of generated .gemspec*: The `+%gemspec_add_dep+` and `+%gemspec_remove_dep+` macros work reliably only on .gemspec generated using the ruby spec command. Please don't use the macros on upstream .gemspec files.
-
-IMPORTANT: *Be sure to test*: Do not simply change versions without testing that the new version works. There are times the upstream is overly strict but there are also times when the version requirement was specified because a specific bug was encountered or the API changed in a minor release.
-
-=== Packaging for Gem and non-Gem use
-
-IMPORTANT: *Packaging for non-Gem use is no longer needed*: Originally, rubygem modules were not placed in ruby's library path, so we packaged rubygems for use with both gems and non-gems. This allowed code that used `require('ARubyModulePackagedAsAGem');` to function. The current `rubygem` module adds all gems to the ruby library path when it is require'd. So, packagers MUST NOT create non-Gem subpackages of rubygems for new packages. Since the majority of Ruby packages in Fedora are now packaged as installed gems, you might need to patch the code to use `require('rubygem')` as early in the program as possible to ensure that these ruby components are properly found. Packages for ruby gems that currently create a non-gem subpackage SHOULD be adapted to stop shipping the non-gem subpackage (with a xref:index.adoc#renaming-or-replacing-existing-packages[proper Obsoletes and Provides] in the main rubygem package).
-
-=== Non-Gem Packages
-
-Non-Gem Ruby packages MUST require ruby-devel package at build time with a `BuildRequires: ruby-devel`, and MAY indicate the minimal ruby version they need for building.
-
-==== Build Architecture and File Placement
-
-The following only affects the files that the package installs into `+%{ruby_vendorarchdir}+` and `+%{ruby_vendorlibdir}+` (the actual Ruby library files). All other files in a Ruby package MUST adhere to the general Fedora packaging conventions.
-
-IMPORTANT: *Site versus Vendor*: Previously, `+%{ruby_sitelibdir}+` and `+%{ruby_sitearchdir}+` were used. However, as they are meant only for local installations, please use `+%{ruby_vendorlibdir}+` and `+%{ruby_vendorarchdir}+` instead.
-
-==== Pure Ruby packages
-
-Pure Ruby packages MUST be built as noarch packages.
-
-The Ruby library files in a pure Ruby package MUST be placed into `+%{ruby_vendorlibdir}+` (or its proper subdirectory). The specfile MUST use this macro.
-
-==== Ruby packages with binary content/shared libraries
-
-For packages with binary content, e.g., database drivers or any other Ruby bindings to C libraries, the package MUST be architecture specific.
-
-The binary files in a Ruby package with binary content MUST be placed into `+%{ruby_vendorarchdir}+` (or its proper subdirectory). The Ruby files in such a package SHOULD be placed into %\{ruby_vendorlibdir}. The specfile MUST use these macros.
-
-For packages which create C shared libraries using `extconf.rb`
-
-....
-export CONFIGURE_ARGS="--with-cflags='%{optflags}'"
-....
-
-SHOULD be used to pass `CFLAGS` to `Makefile` correctly. Also, to place the files into the correct folders during build, pass `--vendor` to `extconf.rb` like this:
-
-....
-extconf.rb --vendor
-....
-
-== Applications
-
-Applications are
-
-* programs that provide user-level tools or
-* web applications, typically built using Rails, Sinatra or similar frameworks.
-
-The RPM packages MUST obey FHS rules. They SHOULD be installed into `+%{_datadir}+`. The following macro can help you:
-
-....
-%global app_root %{_datadir}/%{name}
-....
-
-These packages typically have no `Provides` section, since no other libraries or applications depend on them.
-
-Here's an abbreviated example:
-
-....
-%global app_root %{_datadir}/%{name}
-
-Summary: Deltacloud REST API
-Name: deltacloud-core
-Version: 0.3.0
-Release: 3%{?dist}
-Group: Development/Languages
-License: Apache-2.0 AND MIT
-URL: https://incubator.apache.org/deltacloud
-Source:  https://rubygems.org/gems/%{name}-%{version}.gem
-Requires: rubygem-haml
-#...
-Requires(post):   chkconfig
-#...
-BuildRequires: rubygem-haml
-#...
-BuildArch: noarch
-
-%description
-The Deltacloud API is built as a service-based REST API.
-You do not directly link a Deltacloud library into your program to use it.
-Instead, a client speaks the Deltacloud API over HTTP to a server
-which implements the REST interface.
-
-%package doc
-Summary: Documentation for %{name}
-Group: Documentation
-Requires:%{name} = %{version}-%{release}
-
-%description doc
-Documentation for %{name}
-
-%prep
-%setup -q -n %{name}-%{version}
-
-%build
-
-%install
-mkdir -p %{buildroot}%{app_root}
-mkdir -p %{buildroot}%{_initddir}
-mkdir -p %{buildroot}%{_bindir}
-cp -r * %{buildroot}%{app_root}
-mv %{buildroot}%{app_root}/support/fedora/%{name} %{buildroot}%{_initddir}
-find %{buildroot}%{app_root}/lib -type f | xargs chmod -x
-chmod 0755 %{buildroot}%{_initddir}/%{name}
-chmod 0755 %{buildroot}%{app_root}/bin/deltacloudd
-rm -rf %{buildroot}%{app_root}/support
-rdoc --op %{buildroot}%{_defaultdocdir}/%{name}
-
-%post
-# This adds the proper /etc/rc*.d links for the script
-/sbin/chkconfig --add %{name}
-
-%files
-%{_initddir}/%{name}
-%{_bindir}/deltacloudd
-%dir %{app_root}/
-%{app_root}/bin
-#...
-
-%files doc
-%{_defaultdocdir}/%{name}
-%{app_root}/tests
-%{app_root}/%{name}.gemspec
-%{app_root}/Rakefile
-
-%changelog
-#...
-....
-
-Note, that although the source is a RubyGem, we have to install the files manually under %\{_datadir}/%\{name}, %\{_bindir}, etc. to follow FHS and general packaging guidelines. If additional Fedora specific files (systemd `.service` files, configurations) are required, they SHOULD be
-
-* added via another `+%SOURCE+` tags
-
-....
-Source1: deltacloudd-fedora
-....
-
-* placed into appropriate locations during `+%install+` stage
-
-....
-install -m 0755 %{SOURCE1} %{buildroot}%{_bindir}/deltacloudd
-....
-
-== Running test suites
-
-If there is test suite available for the package (even separately, for example not included in the gem but available in the upstream repository), it SHOULD be run in `+%check+`. The test suite is the only automated tool which can assure basic functionality of the package. Running it is especially helpful when mass rebuilds are required. You MAY skip test suite execution when not all build dependencies are met but this MUST be documented in the specfile. The missing build dependencies to enable the test suite SHOULD be packaged for Fedora as soon as possible and the test suite re-enabled.
-
-The tests SHOULD NOT be run using Rake, as Rake almost always draws in some unnecessary dependencies like hoe or gemcutter. For similar reasons, a dependency on Bundler SHOULD be avoided. Also, code coverage frameworks such as SimpleCov and Coveralls SHOULD be avoided.
-
-=== Testing With Different Ruby Implementations
-
-To run tests with different Ruby implementation such as JRuby, add `BuildRequires: jruby`. Then use Rubypick's interpreter switching:
-
-....
-ruby _jruby_ -Ilib -e 'Dir.glob "./test/test_*.rb", &method(:require)'
-....
-
-If your package is running unittests for ruby-mri and it is intended to run under alternate interpreters then it needs to run the unittests under all alternate interpreters as well. This is the only method we have to check compatibility of the code under each interpreter. The same rules apply that you can omit this if libraries you need are unavailable for a specific alternate interpreter but you MUST have a comment to explain.
-
-=== Testing frameworks usage
-
-The Ruby community supports many testing frameworks. The following sections demonstrate how several to execute test suites using the more common of them.
-
-==== MiniTest / Test::UNIT
-
-MiniTest as well as Test::UNIT are shipped with Ruby. To use them, you need to use `BuildRequires: rubygem-minitest` or `BuildRequires: rubygem-testunit` respectively. To execute the test suite you can use something like:
-
-....
-%check
-ruby -Ilib -e 'Dir.glob "./test/**/*_test.rb", &method(:require)'
-....
-
-You might need to adjust `+-Ilib+` to be `+-Ilib:test+`, or you could need to use a slightly different matching pattern for `+test_*.rb+`, etc. Packagers are expected to use the right pattern for each gem.
-
-==== RSpec
-
-To run tests using RSpec >= 3 you add `BuildRequires: rubygem-rspec` and use something like:
-
-....
-%check
-rspec -Ilib spec
-....
-
-=== Test suites not included in the package
-
-Sometimes you have to get the tests separately from upstream's gem package. As an example lets suppose you're packaging `rubygem-delorean`, version 1.2.0, which is hosted on Github. Tests are not included in the Gem itself, so you need to get them and adjust the specfile accordingly:
-
-....
-# git clone https://github.com/bebanjo/delorean.git && cd delorean
-# git checkout v1.2.0
-# tar -czf rubygem-delorean-1.2.0-specs.tgz spec/
-Source1: %{name}-%{version}-specs.tgz
-
-# ...
-%prep
-%setup -q -n %{gem_name}-%{version} -b 1
-
-# ...
-
-%check
-pushd ./%{gem_instdir}
-# Link the test suite into the right place in source tree.
-ln -s %{_builddir}/spec .
-
-# Run tests
-rspec spec
-popd
-
-# ...
-....
-
-* Make sure to include the version of the tests in the source name, so that when updating to new version, rpmbuild will fail because it won't find the proper `+%{SOURCE1}+` (and this will remind you to update the tests, too).
-* Add the commands you used to get the tests into the specfile as comments. This will make it a lot easier the next time you will need to get them.
-* Run the tests as you normally would.
diff --git a/guidelines/modules/ROOT/pages/Rust.adoc b/guidelines/modules/ROOT/pages/Rust.adoc
deleted file mode 100644
index 53bdce3..0000000
--- a/guidelines/modules/ROOT/pages/Rust.adoc
+++ /dev/null
@@ -1,966 +0,0 @@
-= Rust Packaging Guidelines
-
-:last-reviewed: 2025-11-26
-
-https://www.rust-lang.org[Rust] is a strongly and statically typed,
-compiled programming language
-that supports concepts from both imperative and functional programming.
-
-Because there is not yet a stable Rust ABI,
-and because conditional compilation is a widely used feature in the Rust ecosystem,
-Rust libraries ("crates") can not be distributed in compiled form,
-and are instead distributed as source code.
-
-This document covers how to handle Rust code in packages,
-specific to the different ways in which projects can be set up:
-
-* link:#_rust_crates[Rust "crates"]:
-  packages that are individually published on https://crates.io[crates.io],
-  the official package registry for Rust
-  (primarily libraries, but also "single-crate" applications)
-* link:#_non_crate_rust_projects[Non-crate Rust projects]:
-  Rust projects that are not published on crates.io,
-  or larger projects that are comprised of many crates (cargo workspace)
-* link:#_python_projects[Python projects] with a "native" component implemented in Rust:
-  usually built with https://github.com/PyO3/setuptools-rust[setuptools_rust] or https://github.com/PyO3/maturin[maturin]
-* link:#_mixed_rust_cc_projects[mixed Rust / C/C++ projects] where parts of the project are implemented in Rust:
-  either built by wrapping cargo,
-  or by utilizing https://mesonbuild.com/Rust.html[meson]'s limited support
-  for directly building Rust code
-
-The https://pagure.io/fedora-rust/rust2rpm[rust2rpm] tool can be used
-to generate spec files for Rust crates from cargo / crate metadata.
-It is designed to produce spec files
-that are in line with the (Rust) Packaging Guidelines.
-
-There are also guidelines for link:#_building_shared_libraries_with_cargo_c[packaging shared libraries]
-that are implemented in Rust
-(usually built and installed with https://crates.io/crates/cargo-c[cargo-c]).
-
-
-== Generic rules
-
-This section covers rules that apply to _all_ packages that ship Rust code.
-
-=== Compiler flags
-
-Similarly to other language ecosystems in Fedora,
-there is a standardized set of compiler flags
-that *MUST* be passed to the Rust compiler.
-
-The defaults for Rust are defined in the `%build_rustflags` macro
-from the `rust-srpm-macros` package.
-It is part of the default buildroot on Fedora 39+,
-where the `%set_build_flags` macro automatically sets the `$RUSTFLAGS` environment variable
-based on this macro.
-
-For compatibility with older releases or EPEL,
-this environment variable can be set manually at the start of `%build` and `%check`
-in package's spec files:
-
-[source,shell]
-----
-export RUSTFLAGS="%build_rustflags"
-----
-
-This is not necessary for packages that use the `%cargo_prep`, `%cargo_build`, and `%cargo_test` macros,
-which configure `cargo` to use the default `%build_rustflags` directly.
-
-=== Mandatory `BuildRequires`
-
-The RPM macros that provide basic functionality
-for building Rust code are included in `rust-rpm-macros`,
-which is part of the default buildroot in Fedora,
-as it is a dependency of `redhat-rpm-config`.
-When building for ELN or EPEL8, this is not the case,
-and packages need to use `BuildRequires:  rust-toolset`.
-
-Packages that build Rust code with cargo - directly or indirectly -
-or which call any of the `+%cargo_*+` macros,
-*MUST* add `+BuildRequires:  cargo-rpm-macros+`,
-which provides the implementations of all `+%cargo_*+` macros.
-This package is not part of the default buildroot,
-since it pulls in additional dependencies
-(i.e. a Python interpreter).
-
-=== Dynamically generated `BuildRequires` for crate dependencies
-
-With Semantic Versioning (_"SemVer"_) being
-the only supported versioning scheme for Rust crates,
-dependencies on Rust libraries are almost exclusively specified as
-_"this version or any newer version that is API-compatible with it"_,
-i.e. a range of supported versions.
-
-These ranges of supported versions
-need to be correctly translated into RPM dependencies,
-otherwise a wrong version of a dependency might get pulled in for builds,
-causing unhelpful error messages about missing dependencies.
-
-Since dependencies of Rust projects change frequently,
-packages for projects that build Rust code with cargo
-*MUST* use dynamically generated `BuildRequires`
-by calling the `%cargo_generate_buildrequires` macro
-in the `%generate_buildrequires` scriptlet.
-
-For example, a dependency on `serde = "1.0.100"`
-specified in a project's `Cargo.toml` metadata
-(a dependency on the crate named "serde",
-with version "1.0.100" or any version API-compatible with "1.0.100",
-with default features enabled)
-would cause a dependency like this to be generated for RPM:
-
-....
-BuildRequires:  (crate(serde/default) >= 1.0.100 with crate(serde/default) < 2.0.0~)
-....
-
-Refer to the section about link:#_rpm_macros[RPM macros]
-for how to pass feature flags to this macro.
-
-=== License tags
-
-Similar to other languages that produce statically linked binaries,
-Rust executables (and shared libraries) contain code
-that originates in other packages
-(i.e. packages for other Rust crates),
-which in turn are covered by different license terms.
-
-This needs to be taken into account
-by maintaining a separate `License` tag
-for the subpackage that contains these binaries.
-More information about `License` tags is available from the
-https://docs.fedoraproject.org/en-US/legal/license-field/[Fedora Legal docs].
-
-The `cargo-rpm-macros` package provides two RPM macros
-that help with filling the `License` tag correctly
-for projects that are built with `cargo`:
-
-- `%cargo_license_summary`
-
-This macro determines and prints a summary
-of all the licenses of the Rust crates
-that end up statically linked into final binaries
-(properly excluding build-only or test-only dependencies).
-This summary can then be copied from the build log
-into the spec file as a comment.
-The actual contents of the `License` tag can then be obtained
-by constructing a conjunction of these individial licenses (with SPDX `AND` operators).
-
-- `%cargo_license`
-
-This macro determines and prints a complete breakdown of all Rust crates
-that end up statically linked into final binaries
-(according to the same logic as in the `%cargo_license_summary` macro),
-their versions, _and_ their individual license expressions.
-Generating this list dynamically at build-time
-ensures that its contents always match the actual dependencies.
-
-Both macros accept the same arguments
-as other `%cargo_*` macros (`-a`, `-n`, `-f`),
-and for their output to match the actual binaries,
-the same flags *MUST* be passed to them and `%cargo_build`.
-
-=== Vendored dependencies
-
-https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling[In general],
-packages *SHOULD NOT* use bundled crate dependencies,
-whenever possible.
-
-Whenever vendored / bundled crate dependencies _are_ used
-(no matter which mechanism is used for the purpose),
-all bundled crate dependencies *MUST* be declared
-with virtual `Provides` in the format `Provides: bundled(crate($crate)) = $version`
-in the subpackage that contains the Rust component.
-For example, these virtual `Provides` are used to determine
-the impact of security vulnerabilities on packages
-that use vendored Rust dependencies.
-
-There are also two situations
-in which bundling at least _some_ Rust crates is usually unavoidable:
-
-==== Replacing git dependencies
-
-One of the types of dependencies cargo supports are git snapshots,
-which are usually used to reference either a specific commit,
-or a reference to a downstream fork of a crate.
-
-The project *SHOULD* be patched to use a version of this crate
-that is available on https://crates.io[crates.io] instead,
-if that is possible.
-If it turns out that depending on a git snapshot is no longer necessary,
-this patch *SHOULD* be submitted to the upstream project.
-
-If the dependency is not published on https://crates.io[crates.io],
-or if the versions published there are not a suitable replacement,
-a git snapshot of the crate can be bundled.
-This can be achieved by creating and supplying a tarball
-with the git snapshot as a separate source,
-unpacking the tarball in `%prep`,
-and patching `Cargo.toml` to replace the git-based dependency
-with a path-based dependency.
-Adding this subproject as a workspace member ensures
-that its dependencies are included during dependency resolution.
-
-==== Replacing patched crate sources
-
-Another way in which cargo supports specifying modified dependencies is
-by "patching" a crate source,
-specifying an alternative source for specific crates -
-which will likely be either git references or path-based dependencies
-that are present to override a crate
-that is published on https://crates.io[crates.io] with a (modified) local copy,
-or a git repository that points to a (modified) fork of the crate.
-
-These replacements *SHOULD* be dropped
-in favor of using only published versions of crates.
-If that is not possible,
-they must be replaced by path-based dependencies,
-similar to the process described for link:#_replacing_git_dependencies[git-type dependencies].
-
-==== Using vendor tarballs
-
-Support for building with vendored dependencies
-was added in version 25 of cargo-rpm-macros and rust2rpm.
-
-* The `%cargo_prep` macro accepts a `-v $VENDOR` argument,
-  where `$VENDOR` is the path to the directory
-  that contains the vendored crate dependencies.
-  When this argument is passed,
-  the generated cargo configuration is set up
-  for building against dependencies in this directory
-  instead of dependencies from the system-wide registry.
-* The `%cargo_generate_buildrequires` macro *MUST NOT* be called
-  when using vendored dependencies.
-* The `%cargo_vendor_manifest` macro generates a manifest (`cargo-vendor.txt`)
-  that lists the names and versions of all crates in the vendor tarball.
-  This macro *MUST* be called (for example, in the `%build` scriptlet),
-  and the generated file *MUST* be added as a `%license` file
-  in the appropriate package's list of `%files`.
-  An RPM generator parses this file
-  and generates appropriate virtual `Provides` for all bundled crates,
-  as is required for any bundled dependencies.
-*  Packages that build with vendored dependencies
-  *MUST NOT* provide a Rust library interface (i.e. in `-devel` subpackages),
-  because the resulting packages would have broken dependencies.
-
-Typically, the `%prep` scriptlet will look like this
-when using vendored dependencies
-(assuming `Source1` is the vendor tarball,
-and it contains a top-level `vendor` directory):
-
-[source,rpm]
-----
-%prep
-%autosetup -%{crate}-%{version} -p1 -a1
-%cargo_prep -v vendor
-----
-
-The necessary spec file adaptations
-and the generation of the vendor tarball itself
-happen automatically when running rust2rpm in "vendor" mode.
-
-
-== Rust crates
-
-A large part of the process of packaging Rust crates
-can (and _should_) be automated by using https://pagure.io/fedora-rust/rust2rpm[rust2rpm].
-It is designed to generate spec files that are compliant
-with both the general and the Rust Packaging Guidelines.
-
-Additionally, due to some properties of packages for Rust crates
-(i.e. subpackages that correspond to crate features / optional dependencies),
-https://pagure.io/fedora-rust/rust2rpm[rust2rpm] *MUST* be re-run
-for every new version of a crate
-to ensure that generated feature subpackages
-stays in sync with crate metadata.
-
-=== rust2rpm
-
-The recommended way to write spec files for Rust crates
-is to use https://pagure.io/fedora-rust/rust2rpm[rust2rpm],
-and apply any necessary modifications on top of the generated spec file.
-
-There are a few common situations
-in which automatically generated spec files
-need manual changes:
-
-* invalid `Summary` / `%description`:
-  The heuristics for generating the `Summary` or `%description` for the package
-  from the crate metadata can fail to produce valid values
-  (i.e. `Summary` tag that is too long).
-  In this case, the `Summary` needs to be shortened manually.
-  This can also be overridden
-  in the package-specific rust2rpm configuration file.
-* unwanted dependencies / subpackages:
-  Some crates provide non-default / optional features
-  that are either unnecessary
-  (i.e. only applicable to non-Linux systems),
-  or have additional dependencies
-  that are not packaged for Fedora.
-  These features and unavailable optional dependencies *MUST*
-  be removed from crate metadata - otherwise,
-  the package will either fail to build,
-  or produce subpackages with broken dependencies.
-* nightly-only / unstable features:
-  Some crates provide features
-  that are only available on a nightly version of the Rust compiler,
-  or features that are unstable and require an opt-in
-  by passing environment variables.
-  Features like these *SHOULD* be removed from crate metadata,
-  since they either cannot work
-  (Fedora ships only the stable Rust toolchain)
-  or are not feasible to support.
-* unwanted / unnecessary files ("bloat"):
-  Some projects include files
-  that are not required for the crate to function properly
-  (files for CI settings, development / helper scripts, etc.).
-  Files like these *SHOULD* be prevented from being installed
-  (by adding / modifying the `package.include`
-  or `package.exclude` settings in the crate metadata).
-  It is recommended to submit changes like this to the upstream project.
-* incompatible compiler flags:
-  Some crates include custom settings for the `release` profile
-  that are incompatible with RPM packaging.
-  These settings *MUST* be removed from the `release` profile
-  by patching `Cargo.toml`.
-
-Crates that provide Rust bindings for C libraries
-usually require some additional changes (if possible):
-
-* linking against system libraries:
-  This often requires making some dependencies non-optional and / or
-  modifying `build.rs` scripts to unconditionally link against system libraries
-  instead of building and statically linking a bundled copy of the library.
-* regenerating Rust bindings (and tests for them) at build-time:
-  This too often requires making the `bindgen` dependency non-optional and / or
-  modifying `build.rs` to cause regeneration of Rust bindings at build-time.
-
-Note that patching `Cargo.toml` files
-(especially changing the set of optional dependencies and features)
-*MUST* be done by running `rust2rpm -p`,
-since changes like these affect spec file generation
-(i.e. the list of generated subpackages),
-which is only correctly taken into account
-if the patch is created _before_ generation of the spec file.
-
-It is recommended to track non-empty `+rust2rpm.toml+` configuration files
-in the package repository alongside the generated `+.spec+` file.
-
-=== Package naming
-
-Packages for Rust crates from https://crates.io[crates.io]
-*MUST* use `rust-$crate` as the name of the source package
-(where `$crate` is the name of the project on https://crates.io[crates.io]).
-
-This ensures that there are no name collisions
-between Rust crates published on https://crates.io[crates.io]
-and Rust crates packaged for Fedora.
-
-When generating a package for a Rust crate that contains executable targets,
-the convention followed by https://pagure.io/fedora-rust/rust2rpm[rust2rpm] is
-to generate a subpackage with a name that matches the crate name
-(i.e. the `rust-$crate` source package will have a `$crate` subpackage).
-If necessary, this subpackage can be renamed,
-for example, if the name does not match expectations, or
-if it would conflict with another already existing package.
-
-=== Package versioning
-
-Projects that are built with cargo and / or published on https://crates.io[crates.io]
-follow Semantic Versioning (with small cargo-specific tweaks).
-Since SemVer strings can contain characters that are invalid in RPM version strings,
-they *MUST* be translated to be RPM-compatible.
-
-For example, pre-releases are denoted by a `-<pre>` suffix in SemVer,
-but the `-` character is invalid in RPM Versions.
-This can be solved by replacing `-` with the `~` character,
-which denotes pre-releases in RPM version strings.
-This translation happens automatically for the `Version` tag
-when generating a spec file with https://pagure.io/fedora-rust/rust2rpm[rust2rpm],
-and the "upstream" version is stored in a separate macro
-that can be used to refer to the "original" version string.
-
-Additionally, some Rust crates carry extra "build" metadata in their versions
-(a `+<build>` suffix).
-This format is primarily used to carry information
-about the version of a bundled C library.
-This `+<build>` suffix *MUST* be removed from crate metadata with a patch,
-since it can interfere with RPM dependency / version resolution.
-This happens automatically when using rust2rpm version 25 or newer.
-
-=== Package sources
-
-The canonical source of Rust crates is https://crates.io[crates.io].
-Projects from https://crates.io[crates.io] *MUST* be packaged from the sources
-that are published there (i.e. by using the `+%{crates_source}+` macro).
-
-If the sources published on https://crates.io[crates.io]
-do not contain all files that are necessary for creating the package
-(for example, missing `.desktop` file or man pages),
-the upstream sources can be used as an _additional_ source,
-but they *MUST NOT* be used for building the crate itself.
-It is recommended to file an issue with the upstream project
-about including these additional files in published crates.
-
-Alternatively, if the project in question does not provide a Rust library interface,
-it can be packaged as a link:#_non_crate_rust_projects[Non-crate Rust project]
-using the upstream sources instead.
-
-=== Crate license
-
-Most tooling support for determining licenses
-requires accurate metadata about licenses in crate metadata,
-including the `%cargo_license*` macros,
-and other third-party tools like `cargo-license` and `cargo-deny`.
-
-For this reason, the license metadata for all Rust crates packaged for Fedora
-*MUST* match the license tag of the Fedora package itself.
-Any crates that set `package.license-file` in their metadata
-(which is reserved for non-standard / non-SPDX licenses)
-*MUST* be patched to set `package.license` in their metadata,
-and an accurate SPDX expression *MUST* be provided instead.
-Patches like this *SHOULD* be submitted upstream.
-
-=== Subpackages for crate features
-
-Optional features / dependencies of Rust crates are translated into RPM subpackages
-to support resolving dependencies for features and optional dependencies of crates.
-The list of crate "features"
-(including any implicitly defined features for optional dependencies)
-*MUST* be kept in sync with the list of subpackages,
-i.e. for every feature `$foo` of the crate `$crate`,
-there must be a subpackage with name `rust-$crate+$foo-devel`,
-and vice-versa.
-This is required for RPM generators for `Provides` and `Requires`
-for these optional features / dependencies to work correctly.
-
-If optional features that are _not_ part of the default feature set
-are unused and would pull in additional (possibly unavailable) dependencies,
-the package *MAY* omit subpackages for these specific feature names.
-However, care needs to be taken
-that the features corresponding to the ommitted subpackages
-are not "reachable" via subpackages that have _not_ been omitted,
-since this would result in packages with unsatisfiable dependencies.
-Disabling optional features sometimes cannot be handled correctly
-simply by omitting subpackages for specific features.
-In these cases, the crate metadata in `Cargo.toml`
-needs to be patched accordinly instead.
-
-Beware that the "default" feature is always implicitly defined by cargo,
-even if the crate metadata does not contain a `[features]` table
-or an explicitly defined "default" feature,
-so the subpackage for the "default" feature
-will be present in all packages for Rust crates with a library interface.
-
-=== RPM generators for `Provides` and `Requires`
-
-The cargo-rpm-macros package includes RPM generators
-for automatically generating `Provides` and `Requires`
-for Rust crates that comply with the Packaging Guidelines
-(i.e. install their files into the correct location, `+%{crate_instdir}+`).
-
-It is recommended to verify
-that the generated `Provides` and `Requires` are sane - for example,
-the following `Provides` and `Requires`
-must be present to ensure correct inter-subpackage dependencies:
-
-* the main `rust-$crate-devel` subpackage
-  *MUST* provide `+crate($crate) = %{version}+`
-* the `rust-$crate+$feature-devel` subpackages
-  *MUST* provide `+crate($crate/$feature) = %{version}+`
-  and require `+crate($crate) = %{version}+` (i.e. `rust-$crate-devel`)
-
-Additionally, dependencies on external Rust crates must be as expected:
-
-* the main `rust-$crate-devel` subpackage
-  *MUST* require the virtual `Provides` for all non-optional crate dependencies
-* the `rust-$crate+$feature-devel` subpackages
-  *MUST* require the virtual `Provides` for the optional crate dependencies
-  and features that are listed as the feature's dependencies in crate metadata
-
-=== Packaging multiple versions
-
-In most circumstances,
-the latest version of a crate *SHOULD* be packaged,
-and - if possible - packagers *SHOULD* port crates
-to use the latest available version of their dependencies,
-and submit these patches to upstream
-to limit divergence between the upstream project and the Fedora package.
-
-However, there are two common scenarios
-in which it is often necessary to provide packages
-for multiple versions of a library crate simultaneously:
-
-* It is not feasible to port a crate
-  to the version of a crate dependency in Fedora
-  due to large API changes between the required and the packaged version.
-* The number of packages affected
-  by a required SemVer-incompatible library update is very large.
-
-In these cases, a "compat package" can be created for the older version
-(i.e. usually the current version),
-and the suffix-less package can be updated to the newer version.
-https://pagure.io/fedora-rust/rust2rpm[rust2rpm]
-supports automatically creating "compat packages"
-with names that are compliant with the
-https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple[Naming Guidelines for this case]
-_and_ compatible with the restrictions of Semantic Versioning
-by using the `rust2rpm --compat` flag.
-
-All "compat packages" for Rust crates
-*MUST* follow the guidelines for Rust crates,
-and two additional rules apply when creating them:
-
-* For crates that also includes an executable,
-  only the package for the _latest_ version can include this executable,
-  and it *MUST NOT* be built and included in any older versions,
-  to prevent both the name of the executable under `/usr/bin`
-  and the name of the subpackage would conflict
-  between the old and the new version of the package.
-* The packager *SHOULD* check
-  whether running tests in the old version of the crate
-  would cause additional, potentially undesirable dependencies,
-  for example, older versions of other dependencies
-  that would require creating additional "compat packages" -
-  in this case, tests *SHOULD* be disabled
-  (i.e. by flipping the `check` bcond).
-
-=== The `check` bcond
-
-The behaviour of some RPM macros
-depends on the presence and value of the `_with_check` macro,
-i.e. if `%bcond_without check` or `%bcond_with check`
-are used in the spec file - notably,
-the `%cargo_generate_buildrequires` macro only includes `dev-dependencies`
-(i.e. dependencies that are only used
-for compiling and / or running a project's test suite with cargo)
-if the `check` bcond is enabled.
-
-Additionally, packages for Rust crates
-that are generated by https://pagure.io/fedora-rust/rust2rpm[rust2rpm]
-use the value of this macro to determine if the `%check` scriptlet is run.
-
-Packages for Rust crates *MUST* set this bcond
-to avoid unexpected behaviour of the `%cargo_*` macros,
-by either explicitly _enabling_ or _disabling_ tests.
-
-=== Running tests
-
-Rust crates can have three different kinds of tests in their test suites:
-
-* _"unit tests"_:
-  These tests are included
-  alongside library / application source code in the `src/` directory,
-  and can reference private APIs
-  (similar to "glass-box" tests).
-* _"integration tests"_:
-  These tests are usually separate files under the `tests/` directory,
-  and they can only rely on public API of the tested crate
-  (similar to "black-box" tests).
-* _"doctests"_:
-  These tests are automatically extracted
-  from code blocks in Markdown documentation,
-  which is often used as a mechanism
-  to ensure that code snippets in documentation for public methods
-  are correct and continue to compile.
-
-By default, running `cargo test` (i.e. by calling the `%cargo_test` macro),
-all three kinds of tests are run.
-They can also be invoked separately
-(for example, because parts of the test suite or large data files are
-not included in published sources)
-by passing through filtering arguments
-to the underlying `cargo test` command:
-
-* `%cargo_test -- --lib`: only run _"unit tests"_ for the library interface
-* `%cargo_test -- --bin foo`: only run _"unit tests"_ for binary "foo"
-* `%cargo_test -- --doc`: only run _"doctests"_
-* `%cargo_test -- --test bar`: only run _"integration test"_ "bar"
-
-This can be combined with additional flags
-to skip tests with specific names
-(or that contain a specific string in their name)
-by passing the `--skip` argument through to the test harness
-(can be specified multiple times):
-
-....
-%cargo_test -- --lib -- --skip foo::bar::tests::test1
-....
-
-By default, cargo uses substring matching
-to match `--skip` arguments and actual names of tests,
-which can be turned off by using the `--exact` flag.
-
-If any tests are skipped or disabled,
-the package *SHOULD* include comments
-that explain why this is the case,
-and include links to upstream issues, if available.
-
-
-== Non-crate Rust projects
-
-This section applies to Rust projects
-that are not packaged from sources on crates.io.
-
-The most common cases are
-
-* applications that do not provide a library interface,
-* projects comprised of multiple crates (cargo workspaces)
-  that may or may not be published (or useful) separately, and
-* Python packages implemented in Rust (link:#_python_projects[covered below]).
-
-Packages like this *MUST NOT* ship crate sources in `+%{cargo_registry}+`,
-i.e. they cannot ship `-devel` subpackages that contain crate sources
-or have subpackages that have virtual provides for `+crate(...) = %{version}+`.
-
-=== Package naming
-
-Packages for non-crate Rust projects *MUST* be named according to the generic
-https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/[Naming Guidelines],
-i.e. they *MUST NOT* use a `rust-` prefix for the source package name.
-
-=== Package sources
-
-The generic guidelines for
-https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/[referencing sources] apply.
-
-The `+%{crates_source}+` macro *SHOULD NOT* be used for packages like this,
-even when packaging a Rust crate that is also published on crates.io.
-
-=== RPM macros
-
-Any `-a` and `-n` flags or `-f` arguments
-that are passed to `%cargo_generate_buildrequires`
-are applied to _all_ workspace members during dependency resolution.
-
-The `+%cargo_install+` macro *SHOULD NOT* be used for packages like this.
-Instead, use `install` or `cp` to copy built executables or shared libraries
-from `+target/rpm/*+` into the buildroot explicltly, as needed.
-
-
-== Python projects
-
-Python packages that use https://github.com/PyO3/setuptools-rust[setuptools_rust]
-or https://github.com/PyO3/maturin[maturin]
-to build a "native" Python extension
-also need to apply the link:#_generic_rules[generic rules] for  Rust packages
-in addition to following the
-https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/[Python Packaging Guidelines].
-
-Both https://github.com/PyO3/setuptools-rust[setuptools_rust]
-and https://github.com/PyO3/maturin[maturin]
-build the native Python extension by calling cargo internally,
-so the basic setup for projects that build with cargo
-is required for packages like this as well.
-
-This includes calling `%cargo_prep` in `%prep`
-to set up the build environment for cargo,
-and using `%cargo_generate_buildrequires` to dynamically generate
-the appropriate `BuildRequires` for Rust crate dependencies.
-
-Additionally, `%cargo_license` and / or `%cargo_license_summary`
-*MUST* be used to determine the licenses
-that apply to the statically linked Python extension.
-
-The packager also *MUST* ensure
-that the default link:#_compiler_flags[compiler flags] are passed to rustc,
-and that debuginfo is not stripped during the build process
-due to settings in the `setuptools-rust` or `maturin` configuration.
-
-
-== Mixed Rust / C/C++ projects
-
-Handling of projects that include both C/C++ and Rust code
-depends on how building the Rust code is integrated
-into the project's build system.
-
-Independent of the specific setup,
-the correct link:#_compiler_flags[compiler flags] *MUST* be passed to rustc,
-and the License tag of the package that contains the Rust component
-*MUST* take the licenses of statically linked crates into account.
-
-=== Building with cargo internally
-
-Projects with build systems that call cargo internally to build Rust components
-*MUST* follow the same guidelines
-as other projects that build Rust code with cargo.
-
-Packages *MUST* ensure that the cargo calls
-that are internal to the project's build system
-do not pass flags or arguments that are incompatible
-with either the default link:#_compiler_flags[compiler flags]
-or cargo options that are set in the `%cargo_build`
-macro or configured by `%cargo_prep`.
-
-=== Building with meson directly
-
-Recent versions of https://mesonbuild.com/Rust.html[meson]
-have limited support for building crate dependencies without cargo.
-It is necessary to manually override crate sources
-with the local registry to use packaged crate dependencies.
-
-
-== Building shared libraries with cargo-c
-
-While it is not currently possible
-to build Rust crates as shared libraries,
-Rust projects can define a C-compatible public API
-so that they can be built as standard shared libraries with a C ABI.
-
-In most cases, libraries like this are built with
-https://crates.io/crates/cargo-c[cargo-c],
-which provides convenient wrappers (`cargo-cbuild` and `cargo-cinstall`)
-for both building and installing shared libraries
-(including support for generating and installing header files
-and and pkg-config files).
-
-The `cargo-c` package includes RPM macros for this functionality
-(`%cargo_cbuild` and `%cargo_cinstall`),
-which accept the same arguments as their cargo counterparts.
-
-
-== RPM macros
-
-The process of building and installing Rust projects
-is almost entirely automated with several RPM macros:
-
-* `%cargo_prep`:
-  This macro *MUST* be called in the `%prep` scriptlet
-  after sources have been unpacked.
-  It sets up the build environment for cargo
-  and injects a cargo configuration file,
-  which sets the default compiler flags
-  and configures the local crate registry
-  as a replacement for https://crates.io[crates.io].
-* `%cargo_generate_buildrequires`:
-  This macro *MUST* be called in the `%generate_buildrequires` scriptlet,
-  except when building with vendored dependencies.
-  This is the mechanism that automatically generates depepdencies on other Rust crates
-  based on the metadata in `Cargo.toml`.
-* `%cargo_build`:
-  This macro *MUST* only be called in the `%build` scriptlet
-  unless the build is handled in another way,
-  i.e. "cargo build" is called internally by build scripts.
-  It runs `cargo build` with the appropriate command line arguments.
-  Calling this macro *MAY* be skipped
-  if the crate is not supported on the current CPU architecture.
-* `%cargo_install`:
-  This macro *MUST* only be called in the `%install` scriptlet
-  for crates that provide a library interface.
-  It runs `cargo package` and installs the resulting directory tree
-  into `+%{buildroot}/%{crate_instdir}+`
-  (i.e. `+%{buildroot}/%{cargo_registry}/%{crate}-%{version}/+`).
-  For crates that provide `bin` targets,
-  it installs all built executables into `+%{buildroot}/%{_bindir}+`.
-  If any built executables need to be installed in a different location,
-  they can be moved after calling `%cargo_install`,
-  or `%cargo_install` can be replaced
-  with manual installation steps (copying from `+target/rpm/*+`).
-  To prevent installation of executables by this macro,
-  the `+%cargo_install_bin+` macro can be defined to `0`.
-  To prevent installation of library sources by this macro,
-  the `+%cargo_install_lib+` macro can be defined to `0`.
-* `%cargo_test`:
-  This macro *MUST* only be called in the `%check` scriptlet.
-  It runs `cargo test` with the appropriate command line arguments.
-  Calling this macro *MAY* be skipped
-  if the crate is not supported on the current CPU architecture
-  or if tests are disabled in general.
-* `%cargo_license` / `%cargo_license_summary`:
-  These macros *MUST* be called in the `%build` scriptlet after `%cargo_build`
-  when building crates that include binary targets.
-  They can be used to print the list of the licenses
-  of the crates that are statically linked into any built executable
-  or shared library (see link:#_license_tags[License tags]).
-* `%cargo_vendor_manifest`:
-  This macro *MUST* be called in the `%build` scriptlet after `%cargo_build`
-  when building Rust projects with vendored dependencies.
-  It writes a machine-readable list of all vendored dependencies
-  to `cargo-vendor.txt`, which *MUST* be included as a `%license` file
-  in the package that contains the statically linked executable(s).
-
-All packages for Rust crates *MUST* set
-either `%bcond check 1` or `%bcond check 0`.
-The value of this macro affects whether `%cargo_generate_buildrequires`
-includes dependencies that are required for building and running tests.
-
-Non-crate packages can either use the `%bcond check`
-_or_ pass the `-t` flag to the `%cargo_generate_buildrequires` macro
-to include test-only dependencies in `BuildRequires` generation.
-
-All `%cargo_*` macros (except `%cargo_prep` and `%cargo_vendor_manifest`)
-accept a set of optional flags / arguments
-that can be used to control the feature flags that are passed to cargo
-(usually to enable optional / non-default features):
-
-* `-a`:
-  Causes the `--all-features` flag to be passed to cargo,
-  and the `%cargo_generate_buildrequires` macro
-  to resolve dependencies with all optional features enabled.
-* `-n`:
-  Causes the `--no-default-features` flags to be passed to cargo,
-  and the `%cargo_generate_buildrequires` macro
-  to resolve dependencies with all default and optional features disabled.
-* `-f foo,bar`:
-  Causes the `--features foo,bar` argument to be passed to cargo,
-  and the `%cargo_generate_buildrequires` macro
-  to resolve dependencies with the additional features `foo` and `bar` enabled.
-  This argument accepts a comma-separated list of feature names
-  (or names of optional dependencies).
-
-The `-a` and `-n` flags are mutually exclusive
-and cannot be passed together.
-The `-a` flag and `-f` arguments are also incompatible,
-since passing `-a` already enables all features.
-However, using the `-n` flag and specifically enabling _some_ features
-with the `-f` argument is valid.
-
-There are some common situations
-in which passing these flags or arguments is necessary:
-
-* It can be necessary to enable additional features and / or optional dependencies
-  to build and run the test suite of a crate.
-  In this case, the required features *MUST* be enabled
-  by passing the corresponding flags to all `%cargo_*` macros,
-  unless the required optional dependencies are not packaged yet.
-* Some applications support additional / non-default features
-  by passing feature flags.
-  If it is desirable to build applications with these features enabled,
-  the required features need to be enabled
-  by passing the corresponding flags to all `%cargo_*` macros
-  (including `%cargo_license` and `%cargo_license_summary`).
-
-Note that the `-n` flag should only be used in exceptional circumstances,
-for example when enabling a different backend than the one enabled by default,
-and *MUST NOT* be used to avoid missing dependencies
-that are part of the `"default"` feature set of a crate.
-
-When passing any of the `-a` or `-n` flags or an `-f` argument
-to a `%cargo_build` and / or `%cargo_install` macro,
-the same flags MUST also be passed
-to `%cargo_license` and `%cargo_license_summary` (if present).
-Otherwise, the list of generated licenses and the generated license summary
-will not match what is used when the application or library is compiled.
-
-
-== Templates
-
-=== Non-crate Rust project
-
-[source,rpm]
-----
-Name:           my-awesome-project
-Version:        25.11.26
-Release:        %autorelease
-Summary:        My Awesome Rust Project
-
-SourceLicense:  WTFPL
-# FIXME: paste output of %%cargo_license_summary here
-License:        %{shrink:
-    WTFPL AND
-    ...
-}
-# LICENSE.dependencies contains a full license breakdown
-
-URL:            https://forge.example/me/my-awesome-project
-Source:         %{url}/archive/v%{version}.tar.gz
-
-BuildRequires:  cargo-rpm-macros
-
-%description
-My Awesome Rust Project.
-
-%prep
-%autosetup -p1
-%cargo_prep
-
-%generate_buildrequires
-%cargo_generate_buildrequires -t
-
-%build
-%cargo_build
-%{cargo_license_summary}
-%{cargo_license} > LICENSE.dependencies
-
-%install
-install -Dpm 0755 target/rpm/my-awesome-cli -t %{buildroot}%{_bindir}
-
-%check
-%cargo_test
-
-%files
-%license LICENSE
-%license LICENSE.dependencies
-%doc README.md
-%{_bindir}/my-awesome-cli
-
-%changelog
-%autochangelog
-----
-
-=== Python project
-
-[source,rpm]
-----
-Name:           python-rustypackage
-Version:        25.11.26
-Release:        %autorelease
-Summary:        Rusty Python Package
-
-License:        WTFPL
-URL:            https://forge.example/me/python-rustypackage
-Source:         %{url}/archive/v%{version}/rustypackage-%{version}.tar.gz
-
-BuildRequires:  python3-devel
-BuildRequires:  cargo-rpm-macros
-
-%global _description %{expand:
-My Rusty Python Package.}
-
-%description %_description
-
-%package     -n python3-rustypackage
-Summary:        %{summary}
-
-# FIXME: paste output of %%cargo_license_summary here
-License:        %{shrink:
-    WTFPL AND
-    ...
-}
-# LICENSE.dependencies contains a full license breakdown
-
-%description -n python3-rustypackage %_description
-
-%prep
-%autosetup -n rustypackage-%{version} -p1
-%cargo_prep
-
-%generate_buildrequires
-# maturin requires all dependencies to be available,
-# even those for tests and features that are not enabled
-%cargo_generate_buildrequires -a -t
-%pyproject_buildrequires
-
-%build
-%pyproject_wheel
-%{cargo_license_summary}
-%{cargo_license} > LICENSE.dependencies
-
-%install
-%pyproject_install
-%pyproject_save_files -l rustypackage
-
-%check
-%pyproject_check_import
-# %%pytest
-# %%cargo_test
-
-%files -n python3-rustypackage -f %{pyproject_files}
-%doc README.md
-
-%changelog
-%autochangelog
-----
-
-Verify that project license file(s) *and* the `LICENSE.dependencies` file
-are included in built packages as expected (`+rpm -qL -p <path to RPM>+`)
-when using `+%pyproject_save_files -l+`.
diff --git a/guidelines/modules/ROOT/pages/SSLCertificateHandling.adoc b/guidelines/modules/ROOT/pages/SSLCertificateHandling.adoc
deleted file mode 100644
index c73badc..0000000
--- a/guidelines/modules/ROOT/pages/SSLCertificateHandling.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-= Certificate Handling Guidelines
-
-These guidelines are relevant to maintainers of packages which utilize smart cards for loading certificate or private key. Its purpose is to bring a consistency in smart card handling on the OS; for background and motivation see the link:https://fedoraproject.org/wiki/User:Nmav/Pkcs11Status[current status of PKCS#11 in Fedora].
-
-== How to specify a certificate or private key stored in a smart card or HSM
-
-In April 2015, link:https://tools.ietf.org/html/rfc7512[RFC7512] defined a 'PKCS#11 URI' as a standard way to identify objects stored in smart cards or HSMs. That form should be understood by programs when specified in place of a certificate file. For non-interactive applications which get information on the command line or configuration file, there should not be a separate configuration option to load keys and certificates stored in smart cards, the same option accepting files, should additionally accept PKCS#11 URIs.
-
-== How to specify a specific PKCS#11 provider module for the certificate or key
-
-Packages which can potentially use PKCS#11 tokens SHOULD automatically use the tokens which are present in the system's p11-kit configuration, rather than needing to have a PKCS#11 provider explicitly specified. See xref:Pkcs11Support.adoc[the PKCS#11 packaging page] for more information.
diff --git a/guidelines/modules/ROOT/pages/Scriptlets.adoc b/guidelines/modules/ROOT/pages/Scriptlets.adoc
deleted file mode 100644
index 505b394..0000000
--- a/guidelines/modules/ROOT/pages/Scriptlets.adoc
+++ /dev/null
@@ -1,431 +0,0 @@
-= Scriptlets
-
-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 https://ftp.osuosl.org/pub/rpm/max-rpm/[Maximum RPM book].
-
-The version of RPM in Fedora also has functionality
-to automatically run scripts when files are placed in certain locations.
-(See https://rpm-software-management.github.io/rpm/manual/file_triggers.html[1].)
-This potentially obviates the need for most of the scriptlets on this page,
-but is not currently implemented in all cases where it could be.
-
-Packages MUST NOT rely on writing to stdout / stderr in RPM scriptlets
-for the purpose of communicating non-fatal issues, warnings, or other messages
-to the user.
-
-== Default Shell
-
-In Fedora, all scriptlets can safely assume they are running under the bash shell
-unless a different language has been specified.
-
-== Syntax
-
-The basic syntax is similar to the %build, %install, and other sections
-of the rpm spec file.
-The scripts support a special flag, `+-p+`
-which allows the scriptlet to invoke a single program directly
-rather than having to spawn a shell to invoke the programs.
-(i.e., `+%post -p /usr/bin/ldconfig+`)
-
-When scriptlets are called,
-they will be supplied with an argument.
-This argument, accessed via $1 (for shell scripts)
-is the number of packages of this name
-which will be left on the system when the action completes.
-So for the common case of install, upgrade, and uninstall we have:
-
-[cols=",,,",]
-|===================================
-| |install |upgrade |uninstall
-|`+%pretrans+` |`+$1 == 1+` |`+$1 == 2+` |(N/A)
-|`+%pre+` |`+$1 == 1+` |`+$1 == 2+` |(N/A)
-|`+%post+` |`+$1 == 1+` |`+$1 == 2+` |(N/A)
-|`+%preun+` |(N/A) |`+$1 == 1+` |`+$1 == 0+`
-|`+%postun+` |(N/A) |`+$1 == 1+` |`+$1 == 0+`
-|`+%posttrans+` |`+$1 == 1+` |`+$1 == 2+` |(N/A)
-|===================================
-
-Note that these values will vary
-if there are multiple versions of the same package installed
-(This mostly occurs with parallel installable packages such as
-the kernel and multilib packages.
-However, it can also occur when errors prevent a package upgrade from completing.)
-So it is a good idea to use this construct:
-
-[source,rpm-spec]
-----
-%pre
-if [ $1 -gt 1 ] ; then
-fi
-----
-
-for `+%pre+` and `+%post+` scripts rather than checking that it equals 2.
-
-All scriptlets MUST exit with the zero exit status.
-Because RPM in its default configuration does not execute
-shell scriptlets with the `+-e+` argument to the shell,
-excluding explicit `+exit+` calls
-(frowned upon with a non-zero argument!),
-the exit status of the last command in a scriptlet determines its exit status.
-Most commands in the snippets in this document
-have a "pass:q[`|| :`]" appended to them,
-which is a generic trick to force the zero exit status
-for those commands whether they worked or not.
-Usually the most important bit is to apply this
-to the last command executed in a scriptlet,
-or to add a separate command such as plain "pass:q[`:`]" or "pass:q[`exit 0`]"
-as the last one in a scriptlet.
-Note that depending on the case,
-other error checking/prevention measures may be more appropriate.
-
-Non-zero exit codes from scriptlets can break installs/upgrades/erases
-such that no further actions will be taken for that package in a transaction
-(see <<Ordering>>),
-which may for example prevent an old version of a package
-from being erased on upgrades,
-leaving behind duplicate rpmdb entries
-and possibly stale, unowned files on the filesystem.
-There are some cases where letting the transaction to proceed
-when some things in scriptlets failed
-may result in partially broken setup.
-It is however often limited to that package only
-whereas letting a transaction to proceed
-with some packages dropped out on the fly
-is more likely to result in broader system wide problems.
-
-[#ordering]
-== Ordering
-
-The scriptlets in `+%pre+` and `+%post+` are respectively run
-before and after a package is installed.
-The scriptlets `+%preun+` and `+%postun+`
-are run before and after a package is uninstalled.
-The scriptlets `+%pretrans+` and `+%posttrans+`
-are run at start and end of a transaction.
-On upgrade, the scripts are run in the following order:
-
-1.  `+%pretrans+` of new package
-2.  `+%pre+` of new package
-3.  (package install)
-4.  `+%post+` of new package
-5.  `+%triggerin+` of other packages (set off by installing new package)
-6.  `+%triggerin+` of new package (if any are true)
-7.  `+%triggerun+` of old package (if it's set off by uninstalling the old package)
-8.  `+%triggerun+` of other packages (set off by uninstalling old package)
-9.  `+%preun+` of old package
-10. (removal of old package)
-11. `+%postun+` of old package
-
-12. `+%triggerpostun+` of old package
-(if it's set off by uninstalling the old package)
-
-13. `+%triggerpostun+` of other packages
-(if they're set off by uninstalling the old package)
-
-14. `+%posttrans+` of new package
-
-[#pretrans]
-=== The `+%pretrans+` Scriptlet
-
-Note that 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.
-For this reason, `+%pretrans+` is best avoided,
-but if used it MUST (by necessity) be written in Lua.
-See https://rpm-software-management.github.io/rpm/manual/lua.html
-for more information.
-
-== Writing Scriptlets
-
-Here are some tips for writing good scriptlets:
-
-=== Saving state between scriptlets
-
-Sometimes a scriptlet needs to save some state from an earlier running scriptlet
-in order to use it at a later running scriptlet.
-This is especially common when trying to optimize the scriptlets.
-Examples:
-
-* If a `+%posttrans+` needs to de-register some piece of information when upgrading
-but the file that has that information is removed when the old package is removed
-the scriptlets need to save that file during `+%pre+` or `+%post+`
-so that the script in `+%posttrans+` can access it.
-
-* If we only want the program in `+%posttrans+` to do its work once per-transaction,
-we may need to write out a flag file so that the `+%posttrans+`
-knows whether to perform an action.
-
-To address these issues scriptlets that run earlier need to write out information
-that is used in `+%posttrans+`.
-We recommend using a subdirectory of `+%{_localstatedir}/lib/rpm-state/+`
-for that.
-For instance, the eclipse plugin scripts touch a file in
-`+%{_localstatedir}/lib/rpm-state/eclipse/+` when they're installed.
-The `+%posttrans+` runs a script that checks if that file exists.
-If it does, it performs its action and then deletes the file.
-That way the script only performs its action once per transaction.
-
-=== Macros
-
-If RPM file triggers are not appropriate,
-complex scriptlets which are shared between multiple packages
-MAY be placed in RPM macros.
-This has two benefits:
-
-* The standard package authors only have to remember the macros,
-not the complex stuff that it does
-
-* The macros' implementations may change without having to update the package
-
-When writing the macros, the FPC will still want to review the macros
-(and perhaps include the implementation of the macros in the guideline
-to show packagers what's happening behind the scenes).
-
-One principle that the FPC follows
-is that macros generally don't contain the start of scriptlet tags
-(for instance, `+%pre+`)
-because this makes it difficult to do additional work in the scriptlet.
-This also means that a single macro can not be defined to do things in both
-`+%pre+` and `+%post+`.
-Instead, write one macro that performs the actions in `+%pre+`
-and a separate macro that performs the actions in `+%post+`.
-This principle makes it so that all spec files can use your macros
-in the same manner even if they already have a `+%pre+` or `+%post+` defined.
-
-Of course, in the above situation
-it is better to use RPM file triggers if at all possible.
-
-== Snippets
-
-Some scriptlets to use in specific situations.
-
-=== Linker Configuration Files
-
-Packages which place linker configuration files in `+/etc/ld.so.conf.d+`
-MUST call ldconfig in `+%post+` and `+%postun+` (on all Fedora releases)
-even if they install no actual libraries.
-They MUST NOT use the
-`+%ldconfig+`, `+%ldconfig_post+`,
-`+%ldconfig_postun+` or `+%ldconfig_scriptlets+` macros to do this,
-since these macros do not have any effect on Fedora.
-Instead simply call `+ldconfig+` directly in both
-`+%post+` and `+%postun+`
-as well as adding the necessary dependencies when necessary:
-
-[source,rpm-spec]
-----
-%post -p /usr/bin/ldconfig
-%postun -p /usr/bin/ldconfig
-----
-
-or, as part of existing `+%post+` or `+%postun+` scriptlets:
-
-[source,rpm-spec]
-----
-Requires(post): /usr/bin/ldconfig
-Requires(postun): /usr/bin/ldconfig
-[...]
-%post
-[...]
-ldconfig
-[...]
-%postun
-[...]
-ldconfig
-[...]
-----
-
-If the configuration file added to `+/etc/ld.so.conf.d+` specifies a directory
-into which other packages may install files,
-and that directory is not located in the directory hierarchy beneath one of
-`+/lib+`, `+/usr/lib+`, `+/lib64+` or `+/usr/lib64+`,
-then the package adding the configuration file
-MUST also include the following file triggers
-which cause ldconfig to be run automatically when necessary:
-
-[source,rpm-spec]
-----
-%transfiletriggerin -P 2000000 -- DIRECTORIES
-ldconfig
-
-%transfiletriggerpostun -P 2000000 -- DIRECTORIES
-ldconfig
-----
-
-Replace `+DIRECTORIES+` with the space-separated list of directories
-which the package adds to the library search path
-via the configuration files in `+/etc/ld.so.conf.d+`.
-
-=== Users and groups
-
-These are discussed on a xref:UsersAndGroups.adoc[separate page].
-
-=== GConf
-
-The legacy GNOME 2 configuration system
-(still used by only a handful of packages)
-is documented for posterity on xref:ScriptletsGConf.adoc[another page].
-
-=== Systemd
-
-Packages containing systemd unit files need to use scriptlets
-to ensure proper handling of those services.
-Services can either be enabled or disabled by default.
-To determine which case your specific service falls into,
-please refer to FESCo's policy xref:DefaultServices.adoc[here].
-On upgrade,
-a package may only restart a service if it is running;
-it may not start it if it is off.
-Also, the service may not enable itself if it is currently disabled.
-
-==== Scriptlets
-
-The systemd package provides a set of helper macros
-to handle systemd scriptlet operations.
-These macros support systemd "presets", as documented in
-https://www.freedesktop.org/software/systemd/man/systemd.preset.html[systemd.preset(5)].
-
-[source,rpm-spec]
-----
-BuildRequires: systemd-rpm-macros
-
-[...]
-%post
-%systemd_post apache-httpd.service
-
-%preun
-%systemd_preun apache-httpd.service
-
-%postun
-%systemd_postun_with_restart apache-httpd.service
-----
-
-Some services do not support being restarted
-(e.g. D-Bus and various storage daemons).
-If your service should not be restarted upon upgrade,
-but should be reloaded instead,
-then use the following `+%postun+` scriptlet instead of the one shown above:
-
-[source,rpm-spec]
-----
-%postun
-%systemd_postun_with_reload apache-httpd.service
-----
-
-If your service should not be restarted or reloaded,
-then use the following `+%postun+` scriptlet instead:
-
-[source,rpm-spec]
-----
-%postun
-%systemd_postun apache-httpd.service
-----
-
-Those macros accept multiple unit name arguments.
-It is better to use a single invocation to reduce the number of calls.
-
-If your package includes one or more systemd units
-that need to be enabled by default on package installation,
-they MUST be covered by the xref:DefaultServices.adoc[Fedora preset policy].
-
-===== User units
-
-There are additional macros for user units
-(those installed under `+%_userunitdir+`)
-that should be used similarly to those for system units.
-These enable and disable user units according to presets,
-and are `+%systemd_user_post+` (to be used in `+%post+`)
-and `+%systemd_user_preun+` (to be used in `+%preun+`).
-
-[source,rpm-spec]
-----
-BuildRequires: systemd-rpm-macros
-
-[...]
-%post
-%systemd_user_post %{name}.service
-
-%preun
-%systemd_user_preun %{name}.service
-
-%postun
-%systemd_user_postun_with_restart %{name}.service
-%systemd_user_postun_with_reload %{name}.service
-%systemd_user_postun %{name}.service
-----
-
-Macros `+%systemd_user_postun_with_restart+` and `+%systemd_user_postun_with_reload+`
-iterate over the running user manager instances
-and request the restart and reload operations for the specified units in each one.
-
-===== Dependencies on the systemd package
-
-If package scriptlets call other systemd tools, for example `systemd-tmpfiles`,
-the package SHOULD declare appropriate dependencies.
-The `+%{?systemd_requires}+` macro is a shortcut to require systemd for the
-`%post`, `%preun`, and `%postun` scriptlets.
-Note that those dependencies are **not** required for the
-`%systemd_{post,preun,postun_with_restart,user_post,user_preun}`
-macros listed above.
-
-If the package wants to use systemd tools if they are available,
-but does not want to declare a dependency,
-then the `+%{?systemd_ordering}+` macro MAY be used
-as a weaker form of `+%{?systemd_requires}+`
-that only declares an ordering during an RPM transaction.
-
-NOTE: The macros take the form `+%{?systemd_requires}+`
-instead of `+%systemd_requires+` to allow the specfile to parse properly
-in the case where the systemd macros have yet to be installed.
-
-===== Macro details
-
-For details on what these macros evaluate to, refer to the following sources:
-https://github.com/systemd/systemd/blob/master/src/rpm/macros.systemd.in[macros.systemd.in],
-https://github.com/systemd/systemd/blob/master/src/rpm/triggers.systemd.in[triggers.systemd.in] and
-https://www.freedesktop.org/software/systemd/man/daemon.html[daemon(7)].
-
-=== Shells
-
-`+/etc/shells+` is a text file
-which controls whether an application can be used
-as a system login shell of users.
-It contains the set of valid shells which can be used in the system.
-If you are packaging a new shell,
-you need to add entries to this file that reference the added shells.
-See: `+man 5 SHELLS+` for more information.
-
-As this file can be edited by sysadmins,
-we need to first determine if relevant lines are already in the file.
-If they don't already exist
-then we just need to echo the shell's binary path to the file.
-Since the UsrMove Feature in Fedora 17 made `+/bin+` a symlink to `+/usr/bin+`
-we need to place both paths into the `+/etc/shells+` file.
-Here is an example of the scriptlet to package with shell named "foo":
-
-[source,rpm-spec]
-----
-%post
-if [ "$1" = 1 ]; then
-  if [ ! -f %{_sysconfdir}/shells ] ; then
-    echo "%{_bindir}/foo" > %{_sysconfdir}/shells
-    echo "/bin/foo" >> %{_sysconfdir}/shells
-  else
-    grep -q "^%{_bindir}/foo$" %{_sysconfdir}/shells || echo "%{_bindir}/foo" >> %{_sysconfdir}/shells
-    grep -q "^/bin/foo$" %{_sysconfdir}/shells || echo "/bin/foo" >> %{_sysconfdir}/shells
-fi
-
-%postun
-if [ "$1" = 0 ] && [ -f %{_sysconfdir}/shells ] ; then
-  sed -i '\!^%{_bindir}/foo$!d' %{_sysconfdir}/shells
-  sed -i '\!^/bin/foo$!d' %{_sysconfdir}/shells
-fi
-----
diff --git a/guidelines/modules/ROOT/pages/ScriptletsGConf.adoc b/guidelines/modules/ROOT/pages/ScriptletsGConf.adoc
deleted file mode 100644
index b7e6c10..0000000
--- a/guidelines/modules/ROOT/pages/ScriptletsGConf.adoc
+++ /dev/null
@@ -1,135 +0,0 @@
-= GConf Scriptlets Guidelines
-
-[CAUTION]
-.⚠️ Outdated information
-====
-GConf is the previous configuration scheme used by the GNOME 2.x desktop.
-It was replaced in GNOME 3 by DConf.
-GConf is still used by a half-dozen or so legacy Fedora packages.
-You will not need to deal with GConf
-unless you are maintaining one of those packages.
-
-The remainder of this document is preserved for historical reference.
-====
-
-== Writing GConf Scriptlets
-
-Programs which use GConf setup default values in a `+.schemas+` file
-which is installed under `+%{_sysconfdir}/gconf/schemas/[NAME].schemas+`.
-These defaults are then registered with the gconf daemon
-which monitors the configuration values
-and alerts applications when values the applications are interested in change.
-The schema files also provide documentation
-about what each value in the configuration system means
-(which gets displayed when you browse the database in the gconf-editor program).
-
-For packaging purposes, we have to disable schema installation during build,
-and also register the values in the `+[NAME].schemas+` file
-with the gconf daemon on installation
-and unregister them on removal.
-Due to the ordering of the scriptlets, this is a four step process.
-
-Disabling the GConf installation during the package creation can be done like so: 
-
-[source,rpm-spec]
-----
-%install
-export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1
-make install DESTDIR=$RPM_BUILD_ROOT
-... 
-----
-
-The `+GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL+` environment variable
-suppresses the installation of the schema during the building of the package.
-An alternative for some packages is to pass a configure flag: 
-
-[source,rpm-spec]
-----
-%build
-%configure --disable-schemas
-... 
-----
-
-Unfortunately, this configure switch only works
-if the upstream packager has adapted their `+Makefile.am+` file to handle it.
-If the `+Makefile.am+` file is not configured,
-this switch won't do anything
-and you'll need to use the environment variable instead.
-
-Here's the second part: 
-
-[source,rpm-spec]
-----
-BuildRequires: GConf2
-Requires(pre): GConf2
-Requires(post): GConf2
-Requires(preun): GConf2
-...
-%pre
-%gconf_schema_prepare schema1 schema2
-%gconf_schema_obsolete schema3 
-----
-
-In this section we uninstall old schemas during upgrade using one of two macros.
-
-`+%gconf_schema_prepare+` is used for any current GConf schemas.
-It takes care of uninstalling previous versions of schemas
-that this package currently installs.
-It takes a space separated list of schema names without path or suffix
-that the package installs.
-Note that behind the scenes, this macro works with the `+%post+` scriptlet
-to only process GConf schemas if changes have occurred.
-
-`+%gconf_schema_obsolete+` is used for schemas
-that this package previously provided but no longer does.
-It will deregister the old schema if it is present on the system.
-Nothing will happen if the old schema is not present.
-This macro takes a space separated list of schemas to uninstall.
-One example of using this might be if the package changed names.
-If the old schema was named `+foo.schemas+`
-and the new schema is named `+foobar.schemas+` you'd use: 
-
-[source,rpm-spec]
-----
-%gconf_schema_prepare foobar
-%gconf_schema_obsolete foo 
-----
-
-The next section does the processing of the newly installed schemas: 
-
-[source,rpm-spec]
-----
-%post
-%gconf_schema_upgrade schema1 schema2 
-----
-
-`+%gconf_schema_upgrade+` takes a space separated list of schemas
-that the package currently installs just like `+%gconf_schema_prepare+`.
-Behind the scenes, it does the actual work of registering the new version
-of the schema and deregistering the old version.
-
-The last section is for unregistering schemas when a package is removed: 
-
-[source,rpm-spec]
-----
-%preun
-%gconf_schema_remove schema1 schema2 
-----
-
-When a package is upgraded rpm invokes the `+%pre+` scriptlet
-to register and deregister the schemas.
-When a package is uninstalled, the `+%preun+` scriptlet is used.
-`+%gconf_schema_remove+` takes the list of schemas
-that this package currently provides and removes them for us.
-
-=== Rebuilds for changes to macros
-
-When macros change, packages that make use of them have to be rebuilt
-to pick up the changes.
-This repoquery command can be used to find the schema
-including packages to rebuild:
-
-[source,sh]
-----
-repoquery --whatprovides "/etc/gconf/schemas/*" |sort |uniq |wc -l
-----
diff --git a/guidelines/modules/ROOT/pages/ShellCompletions.adoc b/guidelines/modules/ROOT/pages/ShellCompletions.adoc
deleted file mode 100644
index e9cf43c..0000000
--- a/guidelines/modules/ROOT/pages/ShellCompletions.adoc
+++ /dev/null
@@ -1,48 +0,0 @@
-= Shell Completions
-
-Shell completions are command line completions for a specific shell,
-such as Bash, fish or Zsh.
-
-== RPM Macros
-
-The following macros *MUST* be used instead of hardcoding paths.
-
-[cols=",",options="header"]
-|======================================================================
-| macro                     | definition
-| +%{bash_completions_dir}+ | +%{_datadir}/bash-completion/completions+
-| +%{fish_completions_dir}+ | +%{_datadir}/fish/vendor_completions.d+
-| +%{zsh_completions_dir}+  | +%{_datadir}/zsh/site-functions+
-|======================================================================
-
-
-== Shell Completions Packaging
-
-Shell completion files *MUST* use standard file permissions (0644).
-
-=== Example of shell completions packaging
-
-[source, rpm-spec]
-----
-Name: foo
-...
-
-%install
-...
-
-# Bash completion
-install -Dpm 0644 foo.bash -t %{buildroot}%{bash_completions_dir}
-
-# Fish completion
-install -Dpm 0644 foo.fish -t %{buildroot}%{fish_completions_dir}
-
-# Zsh completion
-install -Dpm 0644 _foo -t     %{buildroot}%{zsh_completions_dir}
-...
-
-%files
-%{bash_completions_dir}/foo.bash
-%{fish_completions_dir}/foo.fish
-%{zsh_completions_dir}/_foo
-
-----
diff --git a/guidelines/modules/ROOT/pages/SourceURL.adoc b/guidelines/modules/ROOT/pages/SourceURL.adoc
deleted file mode 100644
index 28903e8..0000000
--- a/guidelines/modules/ROOT/pages/SourceURL.adoc
+++ /dev/null
@@ -1,331 +0,0 @@
-= Referencing Source
-
-One of the design goals of rpm is to cleanly separate upstream source from vendor modifications.
-For the Fedora packager, this means that sources used to build a package should be the vanilla sources available from upstream.
-To help reviewers and QA scripts verify this,
-the packager needs to indicate where a reviewer can find the source that was used to make the rpm.
-
-The most common case is where upstream distributes source as a `tar.gz`, `tar.bz2` or `zip` archive
-that we can download from an upstream website.
-In these cases you must use a full URL to the package in the `Source:` line.
-For example:
-
-....
-Source: https://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
-
-Source: https://ftp.gnome.org/pub/GNOME/sources/gnome-common/2.12/gnome-common-2.12.0.tar.bz2
-....
-
-[NOTE]
-.Smallest Compressed Archive
-======
-If the upstream source archive is available in multiple compressed formats that our tools can decompress,
-it's best to use the one that is smallest in size.
-This ensures the smallest source rpm to save space on the mirrors and downloads of source RPM packages.
-======
-
-== Using Forges (Hosted Revision Control)
-
-Any software publishing website, permitting the download of source archives via normalized URLs,
-that can be deduced from a project root URL and version, commit, tag, scm, extension… values is a _“forge”_
-that can be supported by the `redhat-rpm-config` `+%{forgemeta}+` macro.
-Common Forge examples are _GitLab_ and _GitHub_.
-`+%{forgemeta}+` centralizes and abstracts our knowledge about those forges,
-so packagers do not have to handle download quirks manually.
-
-`+%{forgemeta}+` makes it easy to switch from release to tag to commit source archives.
-Using `+%{forgemeta}+`,
-forge download URLs or guideline changes are propagated to spec files without manual refactoring.
-
-When those changes result in a different naming or structure of the source archive,
-the source file needs to be uploaded to the build system before rebuilding existing spec files.
-That is the main drawback of using `+%{forgemeta}+`.
-
-The following examples show how to use the Forge macros in various situations.
-
-=== Release Example
-
-.spectemplate-forge-release.spec
-[source]
-----
-include::{examplesdir}/spectemplate-forge-release.spec[]
-----
-
-=== Tag Example
-
-.spectemplate-forge-tag.spec
-[source]
-----
-include::{examplesdir}/spectemplate-forge-tag.spec[]
-----
-
-=== Commit Example
-
-.spectemplate-forge-commit.spec
-[source]
-----
-include::{examplesdir}/spectemplate-forge-commit.spec[]
-----
-
-=== Branch Example
-
-.spectemplate-forge-branch.spec
-[source]
-----
-include::{examplesdir}/spectemplate-forge-branch.spec[]
-----
-
-=== Multiple Sources Example
-
-.spectemplate-forge-multi.spec
-[source]
-----
-include::{examplesdir}/spectemplate-forge-multi.spec[]
-----
-
-== Using Revision Control
-
-In some cases you may want to pull sources from upstream's revision control system
-because there have been many changes since the last release
-and you think that a tarball that you generate from there will more accurately show how the package relates to upstream's development.
-Here's how you can use a comment to show where the source came from:
-
-....
-# The source for this package was pulled from upstream's vcs.  Use the
-# following commands to generate the tarball:
-#  svn export -r 250 https://www.example.com/svn/foo/trunk foo-20070221
-#  tar -cJvf foo-20070221.tar.xz foo-20070221
-Source: foo-20070221.tar.xz
-....
-
-When pulling from revision control,
-please remember to use a Name-version-release compatible with the xref:Versioning.adoc[Versioning] Guidelines.
-In particular, check the section on xref:Versioning.adoc#_complex_versioning[Complex versioning].
-
-[#when-upstream-uses-prohibited-code]
-== When Upstream uses Prohibited Code
-
-Some upstream packages include patents or trademarks that we are not allowed to ship even as source code.
-In these cases you have to modify the source tarball to remove this code before you even upload it to the build system.
-Here's an example of using a script to document how you went from the upstream tarball to the one included in the package:
-
-From the spec:
-
-....
-Source: libfoo-1.0-nopatents.tar.gz
-# libfoo contains patented code that we cannot ship.  Therefore we use
-# this script to remove the patented code before shipping it.
-# Download the upstream tarball and invoke this script while in the
-# tarball's directory:
-# ./generate-tarball.sh 1.0
-Source1: generate-tarball.sh
-....
-
-generate-tarball.sh:
-
-....
-#!/bin/sh
-
-VERSION=$1
-
-tar -xzvf libfoo-$VERSION.tar.gz
-rm libfoo-$VERSION/src/patentedcodec.c
-sed -i -e 's/patentedcodec.c//' libfoo-$VERSION/src/Makefile
-
-tar -czvf libfoo-$VERSION-nopatents.tar.gz libfoo-$VERSION
-....
-
-== Python Packages (pypi)
-
-As PyPI has moved to storing files in directories which change depending on the file being stored,
-it is rather unpleasant to use in a `Source:` URL.
-Instead, files.pythonhosted.org can be used trough the `+%{pypi_source}+` macro,
-followed by the project name.
-
-....
-Source: %{pypi_source foo}
-....
-
-See more about the macro in the xref:Python.adoc#_source_files_from_pypi[Python guidelines].
-
-== Sourceforge.net
-
-For packages hosted on sourceforge, use
-
-....
-Source: https://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
-....
-
-changing `.tar.gz` to whatever matches the upstream distribution.
-Note that we are using `downloads.sourceforge.net` instead of an arbitrarily chosen mirror.
-You may use the package name/package version instead of the `+%{name}+` and `+%{version}+` macros, of course.
-
-Please note that the correct url is `+downloads.sourceforge.net+`, and *NOT* `+download.sourceforge.net+`.
-
-== Git Hosting Services
-
-If the upstream *does* create tarballs you should use them
-as tarballs provide an easier trail for people auditing the packages.
-
-Git web-based hosting services provide a mechanism to create tarballs on demand,
-either from a specific commit revision, or from a specific tag.
-If the upstream does not create tarballs for releases,
-you can use this mechanism to produce them.
-
-The full 40-character hash and associated git tag may be obtained by issuing the following git command:
-
-https://git-scm.com/docs/git-ls-remote[git ls-remote] \https://HOSTING-SERVICE/OWNER/%\{name}.git
-
-....
-HOSTING-SERVICE:  name of the service, i.e. "github.com", "bitbucket.org", "gitlab.com", etc.
-OWNER:            username for the repository owner
-PROJECT:          upstream project name (if it's identical to the package name, use %{name} instead)
-....
-
-You may also obtain the 40-character hash and associated git tag via the web-interface of the HOSTING-SERVICE,
-or by cloning the repository and issuing the https://git-scm.com/docs/git-show-ref[git show-ref] command.
-
-Once the commit hash and git tag are known, you can define them in your spec file as follows:
-
-....
-%global commit 40-CHARACTER-HASH-VALUE
-%global gittag GIT-TAG
-%global shortcommit %(c=%{commit}; echo ${c:0:7})    [GitHub]
-%global shortcommit %(c=%{commit}; echo ${c:0:11})   [Bitbucket]
-%global shortcommit %(c=%{commit}; echo ${c:0:7})    [GitLab]
-%global shortcommit %(c=%{commit}; echo ${c:0:8})    [Sourcehut]
-....
-
-=== Commit Revision
-
-For the source tarball, you can use the following syntax:
-
-....
-Source:  https://github.com/OWNER/PROJECT/archive/%{commit}/%{name}-%{shortcommit}.tar.gz               [GitHub]
-Source:  https://bitbucket.org/OWNER/PROJECT/get/%{commit}.tar.gz#/%{name}-%{shortcommit}.tar.gz        [BitBucket]
-Source:  https://gitlab.com/OWNER/PROJECT/-/archive/%{commit}/%{name}-%{shortcommit}.tar.gz             [GitLab]
-Source:  https://git.sr.ht/~OWNER/PROJECT/archive/%{shortcommit}.tar.gz#/PROJECT-%{shortcommit}.tar.gz  [Sourcehut]
-...
-
-%prep
-%autosetup -n PROJECT-%{commit}              [GitHub]
-%autosetup -n OWNER-PROJECT-%{shortcommit}   [BitBucket]
-%autosetup -n PROJECT-%{commit}              [GitLab]
-%autosetup -n PROJECT-%{shortcommit}         [Sourcehut]
-....
-
-If the release corresponds to a git tag with a sane numeric version,
-you must use that version to populate the `Version:` tag in the spec file.
-If it does not, look at the source code to see if a version is indicated there,
-and use that value.
-If no numeric version is indicated in the code, you may set `Version` to 0,
-and treat the package as a "pre-release" package
-(and make use of the `+%{shortcommit}+` macro).
-See xref:Versioning.adoc#_prerelease_versions[Prerelease versions] for details.
-
-Alternately, if you are using a specific revision that is either a pre-release revision or a post-release revision,
-you must follow the "snapshot" guidelines.
-They are documented here: xref:Versioning.adoc#_snapshots[Snapshots].
-You can substitute `+%{shortcommit}+` for the git hash in `+%{checkout}+` in that section.
-
-=== Git Tags
-
-https://git-scm.com/docs/git-tag[Git tags] represent a particular code point that upstream deems important;
-and are typically used to mark release points.
-
-Bitbucket uses the `+%{shortcommit}+` identifier as part of the archive directory structure;
-regardless of whether you use git tag or Commit Revision to retrieve it.
-This is shown in the %prep section example.
-
-For the source tarball, you can use the following syntax:
-
-....
-Source:  https://github.com/OWNER/PROJECT/archive/%{gittag}/%{name}-%{version}.tar.gz          [GitHub]
-Source:  https://bitbucket.org/OWNER/PROJECT/get/%{gittag}.tar.gz#/%{name}-%{version}.tar.gz   [BitBucket]
-Source:  https://gitlab.com/OWNER/PROJECT/-/archive/%{gittag}/%{name}-%{version}.tar.gz        [GitLab]
-Source:  https://git.sr.ht/~OWNER/PROJECT/archive/%{version}.tar.gz#/PROJECT-%{version}.tar.gz [Sourcehut]
-...
-
-%prep
-%autosetup -n PROJECT-%{gittag}               [GitHub]
-%autosetup -n OWNER-PROJECT-%{shortcommit}    [BitBucket]
-%autosetup -n PROJECT-%{version}              [GitLab]
-%autosetup -n PROJECT-%{version}              [Sourcehut]
-....
-
-== Using %\{version}
-
-Using `+%{version}+` in the `Source:` makes it easier for you to bump the version of a package,
-because most of the time you do not need to edit `Source:` when editing the spec file for the new package.
-
-== Troublesome URLs
-
-When upstream has URLs for the download that do not end with the tarball name
-rpm will be unable to parse the tarball out of the source URL.
-One workaround for many cases is to construct a URL where the tarball is listed in a "URL fragment":
-
-....
-Source: https://example.com/foo/1.0/download.cgi#/%{name}-%{version}.tar.gz
-....
-
-rpm will then use `+%{name}-%{version}.tar.gz+` as the tarball name.
-If you use `+spectool -g foo.spec+` to download the tarball,
-it will rename the tarball for you.
-
-Sometimes this does not work because the upstream cgi tries to parse the fragment
-or because you need to login or fill in a form to access the tarball.
-In these cases, you have to put just the tarball's filename into the `Source:` tag.
-To make clear where you got the tarball,
-you should leave notes in comments above the `Source:` line
-to explain the situation to reviewers and future packagers.
-For example:
-
-....
- # Mysql has a mirror redirector for its downloads
- # You can get this tarball by following a link from:
- # https://dev.mysql.com/downloads/mysql/5.1.html
- Source: mysql-5.1.31.tar.gz
-....
-
-== Do not conditionalize Sources
-
-When building an SRPM, it is critical that all of the sources are present,
-irrespective of the platform on which the SRPM is generated.
-For example, the following code  *does not work* (the way you might expect):
-
-....
-%if 0%{?fedora} < 35
-Source1: mysource-old.tar.bz2
-Patch1: oldpatch.patch
-%else
-Source1: mysource-ng.tar.bz2
-Patch1: ngpatch.patch
-%endif
-....
-
-If you were to build this SRPM from a Fedora 34 host (`rpmbuild -bs mysource.spec`),
-the resulting SRPM would carry `mysource-old.tar.bz2` and `oldpatch.patch`.
-However, if you then try to use this SRPM to build for Fedora 35,
-the operation would fail because `mysource-ng.tar.bz2` is not available.
-
-The correct behavior is to always carry all of the sources that might be used in the build
-and then conditionalize the *usage* of them instead. For example:
-
-```
-Source1: mysource-old.tar.bz2
-Source2: mysource-ng.tar.bz2
-
-Patch1: oldpatch.patch
-Patch2: ngpatch.patch
-...
-%prep
-%autosetup -N
-...
-%if 0%{?fedora} < 35
-tar xf %{SOURCE1}
-%patch 1 -p1
-%else
-tar xf %{SOURCE2}
-%patch 2 -p1
-%endif
-```
diff --git a/guidelines/modules/ROOT/pages/SugarActivityGuidelines.adoc b/guidelines/modules/ROOT/pages/SugarActivityGuidelines.adoc
deleted file mode 100644
index 0c3559c..0000000
--- a/guidelines/modules/ROOT/pages/SugarActivityGuidelines.adoc
+++ /dev/null
@@ -1,107 +0,0 @@
-= Sugar Activity Packaging Guidelines
-
-These guidelines are for packaging Sugar activities. http://wiki.laptop.org/go/Sugar[Sugar] is the core of the OLPC Human Interface.
-
-== Macros
-
-Sugar looks for its activities in two fixed locations, which are defined in sugar-toolkit with rpm macros:
-
-Architecture Independent (noarch):
-
-....
-%global sugaractivitydir /usr/share/sugar/activities/
-....
-
-Architecture Dependent:
-
-....
-%global sugarlibdir %{_libdir}/sugar/activities
-....
-
-== Necessary BuildRequires
-
-All Sugar Activities use setup.py, which is dependant upon sugar-toolkit. Accordingly, all activities need to:
-
-....
-BuildRequires: sugar-toolkit
-....
-
-== Naming
-
-All activities *MUST* be named `+sugar-+`.
-
-== Architecture-specific Activities
-
-All activities containing compiled code (thus, architecture-specific) must be built in the %build section. Any architecture-specific bits must either go in `+%{_bindir}+` `+%{_libdir}+` or `+%{sugarlibdir}+` as appropriate.
-
-== Runtime Dependencies
-
-All runtime dependency information *MUST* be manually added. There is no build time detection for Sugar activities.
-
-== Sample SPEC
-
-....
-Name:           sugar-journal
-Version:        79
-Release:        1%{?dist}
-Summary:        Journal for Sugar
-
-Group:          Sugar/Activities
-License:        GPL-2.0-or-later
-URL:            http://wiki.laptop.org/go/Journal
-Source:         journal-activity-%{version}.tar.bz2
-Source1:        sugar-journal-checkout.sh
-BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
-BuildRequires:  python sugar-toolkit
-Requires:       sugar
-BuildArch:      noarch
-
-%description
-The Journal activity provides an intuitive interface for viewing projects and
-files saved by the XO user. Activities that the user has stopped will show in
-the journal view with a timer showing how long ago they were stopped.
-
-%prep
-%setup -q -n journal-activity-%{version}
-
-
-%build
-
-
-%install
-rm -rf $RPM_BUILD_ROOT
-mkdir -p $RPM_BUILD_ROOT%{sugaractivitydir}
-./setup.py install $RPM_BUILD_ROOT%{sugaractivitydir}
-
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
-%files
-%doc NEWS
-%{sugaractivitydir}/Journal.activity/
-
-
-%changelog
-* Fri Apr 04 2008 Dennis Gilmore <dennis@ausil.us> - 79-1
-- Initial packaging
-....
-
-== Sample Checkout Script
-
-....
-#!/bin/bash
-
-VERSION=79
-NAME=journal-activity
-
-rm -rf $NAME-$VERSION
-
-git clone git://dev.laptop.org/$NAME $NAME-$VERSION
-
-tar -cjvf $NAME-$VERSION.tar.bz2 $NAME-$VERSION
-
-rm -rf $NAME-$VERSION
-....
diff --git a/guidelines/modules/ROOT/pages/Systemd.adoc b/guidelines/modules/ROOT/pages/Systemd.adoc
deleted file mode 100644
index 8a59dc0..0000000
--- a/guidelines/modules/ROOT/pages/Systemd.adoc
+++ /dev/null
@@ -1,668 +0,0 @@
-= Fedora systemd Services
-
-This document describes the guidelines for systemd services,
-for use and inclusion in Fedora packages.
-
-[#definitions]
-== Definitions
-
-Since systemd includes some concepts which are extensions of previous concepts,
-the following definitions may be useful:
-
-Service::
-A process or task executed and controlled by the init system
-(e.g. systemd).
-
-Traditional Service:: A service which is explicitly started or stopped,
-either by the init system at boot
-or manually by a superuser.
-In systemd, one of several types of service controlled by a `+.service+` file.
-
-Activated service::
-A service that is not (or not necessarily) started explicitly by the user
-but start when certain other events happen
-or certain state becomes true.
-
-Socket-activated Service::
-A service which is waiting for traffic across a socket
-before activating.
-In systemd, controlled by a `+.socket+` file.
-
-D-Bus service::
-A service which activates in response to a message from the D-Bus system bus.
-
-Unit file::
-The systemd equivalent of a SysV initscript.
-[#unit_files]
-== Unit Files
-
-Each package that contains software that wants/needs
-to start a traditional service at boot
-MUST have a systemd unit file.
-
-Ideally, systemd unit files are reusable across distributions
-and shipped with the upstream packages.
-Please consider working with upstream
-to integrate the systemd files you prepare in the upstream sources.
-Information for developers on how to integrate systemd support best with their build system
-you may find in
-https://www.freedesktop.org/software/systemd/man/daemon.html[daemon(8)].
-
-[#unit_files_naming]
-=== Naming
-
-Unit files for traditional services have a naming scheme of `+foobar.service+`.
-When considering what basename to use,
-keep in mind that we'd like to use the same service names for software across distributions.
-We'd also like to ship the `+.service+` files in the upstream packages.
-These desires create a few guides for naming a unit file:
-
-* Follow upstream if they're already distributing a `+.service+` file
-and it's not likely to conflict with other packages.
-
-* Look at packages in other distros
-or talk with the maintainers of those packages and upstream
-to try to come up with a common name.
-
-* Unit files should be named after the software implementation that they support
-as opposed to the generic type of software.
-So, a good name would be `+apache-httpd.service+`
-and bad names would be `+httpd.service+` or `+apache.service+`
-as there are multiple httpd implementations
-and multiple projects produced by the apache foundation.
-
-For backwards compatibility
-you may also want to create a symlink from an older, name to the new name.
-In the above example, for instance,
-Fedora has always used `+httpd+` for the service.
-When creating the new `+apache-httpd.service+` file,
-also create a symlink named `+httpd.service+`
-that points at `+apache-httpd.service+`.
-Then end users that are used to using `+service httpd+`
-will have it continue to work.
-
-[#unit_files_basic_format]
-=== Basic format
-
-[#unit_files_basic_format_unit]
-==== [Unit]
-
-Every `+.service+` file must begin with a `+[Unit]+` section:
-
-....
-[Unit]
-Description=A brief human readable string describing the service (not the .service file!)
-Documentation=man:foo.service(8) man:foo.conf(5) https://www.foo.org/docs/
-....
-
-The `+Description=+` line must not exceed 80 characters,
-and must describe the service, and not the `+.service+` file.
-For example, "Apache Web Server" is a good description,
-but "Starts and Stops the Apache Web Server" is a bad one.
-
-[#unit_files_basic_format_unit_doc]
-===== Documentation field
-
-Systemd has support for defining documentation in unit files
-via the `Documentation=` field.
-System administrators will be looking at the contents of the `+Documentation=+` field
-to determine what the service is,
-how to configure it,
-and where to locate additional documentation relating to the service.
-Accordingly, packagers are strongly encouraged
-to include any available sources in the `Documentation=` field
-which provide this information.
-If a man page or info page is present in the package,
-refer to it using `man:manpage` or `info:infofile` respectively.
-If the documentation is in plaintext, use `\file://path/to/file`.
-Lastly, if no local documentation exists in the package,
-but it exists at a URL,
-use the URL (with `https://`) in this field.
-Multiple URIs can be added to the `Documentation=` field,
-as a space separated list.
-For details on URI definitions and formatting,
-please refer to the `uri(7)` manpage (`man uri`).
-
-[#unit_files_basic_format_service]
-==== [Service]
-
-Next, the `+.service+` file must have a `+[Service]+` section:
-
-....
-[Service]
-Type=...
-ExecStart=...
-ExecReload=...
-....
-
-The `+Type=+` setting is very important.
-For D-Bus services this should be `+dbus+`,
-for traditional services `+forking+` is usually a good idea,
-for services not offering any interfaces to other services `+simple+` is best.
-For "one-shot" scripts `+oneshot+` is ideal,
-often combined with `+RemainAfterExit=+`.
-See https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd.service(5)]
-for further discussion on the topic.
-Since `+simple+` is the default type,
-`+.service+` files which would normally set `+Type=simple+`
-may simply omit the `+Type+` line altogether.
-
-`+BusName=+` should be set for all services connecting to D-Bus.
-(i.e. it is a must for those where `+Type=dbus+`,
-but might make sense otherwise, too)
-Omit this option if your service does not take a name on the bus.
-
-`+ExecStart=+` is necessary for all services.
-This line defines the string that you would run to start the daemon,
-along with any necessary options.
-
-`+ExecReload=+` should be specified for all services supporting reload.
-It is highly recommended to add code here
-that synchronously reloads the configuration file here
-(i.e. `+/bin/kill -HUP $MAINPID+` is usually a poor choice,
-due to its asynchronous nature).
-Omit this option if your service does not support reloading.
-
-[#unit_files_basic_format_install]
-==== [Install]
-
-Finally, the `+.service+` file should have an `+[Install]+` section:
-
-....
-[Install]
-WantedBy=...
-....
-
-The recommended parameters for `+WantedBy=+` are either
-`+graphical.target+` (services related to the graphical user interface)
-or `+multi-user.target+` (for everything else).
-When the user (or our scriptlets) invoke `+systemctl enable+`
-the service will be set to start in these targets.
-
-For more information regarding these options
-see https://www.freedesktop.org/software/systemd/man/systemd.unit.html[systemd.unit(5)]
-and https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd.service(5)].
-
-[#unit_files_env]
-=== EnvironmentFiles and support for /etc/sysconfig files
-
-The `+EnvironmentFiles=+` line in the `+[Service]+` section of `+.service+` files
-is used to support loading environment variables that can be used in unit files.
-For instance,
-if your sysv-initscript used a file in `+/etc/sysconfig+` to set command line options,
-you can use `+EnvironmentFiles=+` like so:
-
-Example:
-
-....
-[Service]
-Type=forking
-EnvironmentFile=-/etc/sysconfig/httpd
-ExecStart=httpd $OPTIONS
-ExecReload=httpd $OPTIONS -k restart
-....
-
-You may then refer to variables set in the `+/etc/sysconfig/httpd+` file
-with `+${FOOBAR}+` and `+$FOOBAR+`,
-in the `+ExecStart=+` lines (and related lines).
-(`+${FOOBAR}+` expands the variable into one word,
-`+$FOOBAR+` splits up the variable value at whitespace into multiple words)
-
-The `+-+` on the `+EnvironmentFile=+` line
-ensures that no error messages is generated
-if the environment file does not exist.
-Since many of these files were optional in sysvinit,
-you should include the `+-+` when using this directive.
-
-[#unit_files_avoid]
-=== Fields to avoid
-
-For most services,
-we do not want to use requirement dependencies in the `+[Unit]+` section,
-such as `+Requires=+` or `+Wants=+`.
-Instead exclusively use ordering dependencies:
-`+Before=+` and `+After=+`.
-This is used to implement loose coupling:
-if someone asks two services to start at the same time,
-systemd will properly order their startup
-but not make it strictly necessary to run one if the other is started.
-
-If you use a requirement dependency,
-use `+Wants=+` rather than `+Requires=+`,
-to make things a little bit more robust.
-If you use a requirement dependency
-in almost all cases you should also add an ordering dependency,
-as ordering and requirement dependencies are orthogonal in systemd.
-
-Here's an example of this common case:
-
-. A web application needs postgresql to store its data.
-
-. It is set to start `+After+` postgresql.
-On startup, the web application does not start until postgresql does.
-
-. Once running,
-the system administrator needs to restart postgresql due to a config tweak.
-
-.  Since only `+After+` was used,
-the web application may be temporarily unable to serve some requests
-but it does not need to restart in order to serve pages
-after the database comes back up.
-
-Avoid referring to `+runlevelX.target+` units in all lines taking unit names
-(such as `+WantedBy+`),
-these are legacy names existing for compatibility with SysV only.
-
-Avoid `+Names=+` (in the `+[Unit]+` section).
-Usually it is a better idea to symlink an additional name in the file system.
-Note that a name listed in `+Names=+` is only useful
-when a service file is already loaded.
-However, systemd loads only the service files actually referred to
-in another loaded service,
-and uses the filenames during the search.
-Hence a name in `+Names=+` is not useful as a search key,
-but a symlink in the file system is.
-Also do not put a (redundant) `+Names=foobar.service+` line
-into a file called `+foobar.service+`.
-We want to keep our service files short.
-
-Unit files should avoid using `+StandardOutput=+` or `+StandardError=+`.
-The default is the right choice for almost all cases,
-and using the default allows users to change global defaults
-in /etc/systemd/system.conf.
-
-[#unit_files_example]
-=== Example Unit file
-
-This is an example systemd unit `+.service+` file for ABRT:
-
-....
-[Unit]
-Description=ABRT Automated Bug Reporting Tool
-
-[Service]
-Type=dbus
-BusName=com.redhat.abrt
-ExecStart=abrtd -d -s
-
-[Install]
-WantedBy=multi-user.target
-....
-
-[#activation]
-== Activation
-
-Systemd allows for the following forms of activated services:
-xref:#activation_hardware[Hardware activation],
-xref:#activation_socket[Socket activation],
-xref:#activation_timer[Timer activation],
-and xref:#activation_dbus[DBus activation].
-
-[#activation_hardware]
-=== Hardware activation
-
-Hardware activation occurs when a service is installed
-but only turns on if a certain type of hardware is installed.
-Enabling of the service is normally done with a udev rule.
-At this time we do not have further guidance on how to write those udev rules.
-The service itself installs its `+.service+` files in the normal places
-and are installed by the normal xref:Scriptlets.adoc#_systemd[systemd scriptlets]. These services should never be enabled by the package
-as they will be enabled by udev.
-
-[#activation_socket]
-=== Socket activation
-
-Socket activation occurs when a service allows systemd to listen for connections to a specific socket
-and, when systemd receives a connection on that socket,
-it starts the service.
-To do this, the upstream source needs to have some minor coding work
-to let systemd listen for connections on the socket
-and there needs to be a `+.socket+` file in `+%{_lib}/systemd/system/+`
-that tells systemd to listen to that socket
-and what to start when a connection is received.
-This is similar in function to inetd
-and some, but not all, services coded to work with inetd
-will work with socket activation.
-
-However, socket activation can also be used to allow parallel startup of services.
-If a service supports systemd socket activation as described above
-and we additionally start it explicitly on boot,
-then systemd will start it
-but allow things that depend on it to startup at the same time.
-If the dependent service makes a request to the socket activatable service before it has come up,
-then systemd will cause the request to wait
-until the socket activatable service has come up and can process the request.
-To achieve this effect,
-the service must be socket activatable as described above,
-the `+.service+` file for the service needs to have a `+Wants=+` line for the `+.socket+`,
-and the service must autostart.
-
-Note that certain socket activated services
-(notably network listening ones)
-require FESCo approval —
-see xref:DefaultServices.adoc[Default Services] for details.
-Once you have permission,
-you can package the `+.socket+` file
-and use the systemd scriptlets that enable the service by default.
-You need to also check the `+.service+` file
-to make sure it has a `+Wants=+` entry on the `+.socket+` file
-as that ensures that starting the service will also inform systemd of the socket.
-
-[#activation_timer]
-=== Timer activation
-
-All packages with timed execution which already depend on systemd
-(for example because they contain systemd units)
-must use timer units instead of cron jobs,
-with no dependency or requirements on a crontab.
-
-Packages which do not already depend or require systemd must not use timer units
-but instead depend and have requirement on crontabs,
-to avoid introducing unnecessary new dependencies on systemd directly.
-
-[#activation_dbus]
-=== DBus activation
-
-In order to allow parallel startup of a D-Bus service and its consumers
-it is essential that D-Bus services can be bus activated
-and the D-Bus activation request is forwarded from the D-Bus system bus to systemd
-so that you end up with only a single instance of the service,
-even if a service is triggered by both boot-up and activation.
-If historically your D-Bus service was not bus-activated
-but started via a SysV init script,
-it should be updated to use bus activation.
-This may be implemented
-by dropping a D-Bus `+.service+` file in `+/usr/share/dbus-1/system-services/+`
-and use the `+SystemdService=+` directive therein
-to redirect the activation to systemd.
-
-Here's an example for a D-Bus bus-activable service.
-The ConsoleKit bus activation file
-`+/usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service+`:
-
-....
-[D-BUS Service]
-Name=org.freedesktop.ConsoleKit
-Exec=console-kit-daemon --no-daemon
-User=root
-SystemdService=console-kit-daemon.service
-....
-
-And the matching systemd unit file
-/usr/lib/systemd/system/console-kit-daemon.service:
-
-....
-[Unit]
-Description=Console Manager
-
-[Service]
-Type=dbus
-BusName=org.freedesktop.ConsoleKit
-ExecStart=console-kit-daemon --no-daemon
-....
-
-As you can see `+SystemdService=+` is used in the D-Bus activation file
-to bind the systemd service to the D-Bus service.
-
-Traditionally,
-bus activated D-Bus services could not be disabled
-without uninstalling them entirely.
-systemd allows you to disable services
-by making D-Bus invoke an alias systemd service name
-(that can be created or removed to enable/disable activation)
-as an intermediary for the real service.
-
-You can easily implement disabling
-by directing the D-Bus service to an alias name of the real service file
-(in the filesystem this shows up as a symlink
-placed in `+/etc/systemd/system+` to the real service file).
-This alias is then controlled via `+systemctl enable+` and `+systemctl disable+`.
-It is a good idea
-(though technically not necessary)
-to name this alias name after the D-Bus bus name of the service,
-prefixed with `+dbus-+`.
-Example for Avahi, a service that the admin might need to disable:
-set `+SystemdService=dbus-org.freedesktop.Avahi.service+`
-instead of `+SystemdService=avahi-daemon.service+` in the D-Bus activation file,
-and then make `+dbus-org.freedesktop.Avahi.service+` an optional alias of avahi-daemon.service
-that can be controlled via the `+Alias=+` directive
-in the `+[Install]+` section of the systemd service file.
-This directive is then read by `+systemctl enable+` and `+systemctl disable+`
-to create resp. remove a symlink
-to make the service available resp. unavailable under this additional name.
-A full example for the Avahi case:
-
-Here is the D-Bus .service file for Avahi
-(`+/usr/share/dbus-1/system-services/org.freedesktop.Avahi.service+`):
-
-....
-[D-BUS Service]
-Name=org.freedesktop.Avahi
-SystemdService=dbus-org.freedesktop.Avahi.service
-
-# This service should not be bus activated if systemd isn't running,
-# so that activation won't conflict with the init script startup.
-Exec=false
-....
-
-Here is the Avahi systemd unit `+.service+` file
-(`+/usr/lib/systemd/system/avahi-daemon.service+`):
-
-....
-[Unit]
-Description=Avahi mDNS/DNS-SD Stack
-Requires=avahi-daemon.socket
-
-[Service]
-Type=dbus
-BusName=org.freedesktop.Avahi
-ExecStart=avahi-daemon -s
-ExecReload=avahi-daemon -r
-NotifyAccess=main
-
-[Install]
-WantedBy=multi-user.target
-Also=avahi-daemon.socket
-Alias=dbus-org.freedesktop.Avahi.service
-....
-
-The `+Alias=+` line ensures
-that the existance of the `+/etc/systemd/system/dbus-org.freedesktop.Avahi.service+` symlink
-can be controlled by `+systemctl enable+` and `+systemctl disable+`.
-
-Note that the creation/removal of the alias symlinks
-should be done with `+systemctl enable+` and `+systemctl disable+` only.
-You should not create these symlinks manually.
-
-In general,
-it is also recommended to supply native systemd units
-for all services that are already bus activatable,
-so that these services can be controlled and supervised centrally
-like any other service with tools such as systemctl.
-A similar logic like the one shown above should apply.
-
-See the D-Bus documentation for more information about bus activation:
-https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services
-
-[#automatic_restart]
-== Automatic restarting
-
-If you package a long-running service,
-please consider enabling systemd's automatic restart feature for it,
-to improve reliability
-by making sure the system automatically attempts recovering a failing daemon.
-Please use
-
-....
-[Service]
-...
-Restart=on-failure
-....
-
-or
-
-....
-[Service]
-...
-Restart=on-abnormal
-....
-
-in your unit's `+.service+` file for this.
-
-The former will tell systemd to restart the daemon as soon as it fails
-regardless of the precise reason.
-It's a good choice for most long-running services.
-Some daemons require a way to escape constant restarting
-by exiting with any non-zero exit code.
-For those services use `+Restart=on-abnormal+`,
-which will still restart the daemon when it fails "abnormally",
-on unclean signal,
-core dump,
-timeout
-or watchdog exits,
-but not on unclean exit codes.
-It is recommended to to enable automatic restarts for all long-running services,
-but which setting is the right one,
-and whether it is useful at all
-depends on the specific service.
-Please consult the
-https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd.service(5)] man page
-for more information on the various settings.
-
-[#private]
-== Private devices and networking
-
-If you package a long-running system service,
-please consider enabling systemd's `+PrivateDevices=+` and `+PrivateNetwork=+` settings for it,
-in order to improve security and minimize the attack surface.
-
-When `+PrivateDevices=yes+` is set in the `+[Service]+` section
-of a systemd service unit file,
-the processes run for the service will run in a private file system namespace
-where `+/dev+` is replaced by a minimal version
-that only includes the device nodes
-`+/dev/null+`,
-`+/dev/zero+`,
-`+/dev/full+`,
-`+/dev/urandom+`,
-`+/dev/random+`,
-`+/dev/tty+`
-as well as the submounts
-`+/dev/shm+`,
-`+/dev/pts+`,
-`+/dev/mqueue+`,
-`+/dev/hugepages+`,
-and the `+/dev/stdout+`, `+/dev/stderr+`, `+/dev/stdin+` symlinks.
-No device nodes for physical devices will be included, however.
-Furthermore, the CAP_MKNOD capability is removed.
-Finally, the `+devices+` cgroup controller is used
-to ensure that no access to device nodes except the listed ones is possible.
-This is an efficient way to take away physical device access for services,
-thus minimizing the attack surface.
-
-When `+PrivateNetwork=yes+` is set in the `+[Service]+` section
-of a systemd service unit file,
-the processes run for the service will run in a private network namespace
-whith a private loopback network interface,
-and no other network devices.
-Network communication between host and service can not be initiated.
-This is an efficient way to take away network access for services,
-thus minimizing the attack surface.
-
-By default both switches default to `+no+`.
-
-Note that `+PrivateDevices=yes+` should not be used for:
-
-* Services that actually require physical device access
-
-* Services which may be used to execute arbitrary user or administrator supplied programs
-(such as cron, ...).
-We shouldn't limit what people can do with these services.
-
-* This option creates a new file system namespace
-where mount/umount propagation is turned off back into the host.
-This means that mounts made by the service will stay private to the service.
-Thus this option should not be used by services which shall be able to establish mounts in the host.
-
-Note that `+PrivateNetwork=yes+` should not be used for:
-
-* Services that actually require network access
-(with the exception of daemons only needing socket activation)
-
-* Services which may be used to execute arbitrary user or administrator supplied programs.
-(see above)
-
-* Services which might need to resolve non-system user and group names.
-Since on some setups resolving non-system users might require network access to an LDAP or NIS server,
-enabling this option on might break resolving of these user names.
-Note however that system users/groups are always resolvable
-even without network access.
-Hence it is safe to enable this option for daemons which just need to resolve their own system user or group name.
-
-* This also disconnects the AF_UNIX abstract namespace from the host
-(In case you wonder what this refers to:
-sockets listed in `+/proc/net/unix+` that start with an `+@+`
-are in the abstract namespace,
-those which start in `+/+` are in the file system namespace).
-This means that services which listen or connect to AF_UNIX sockets in the abstract namespaces might break.
-AF_UNIX sockets in the file system continue to work correctly even with `+PrivateNetwork?=yes+`.
-We strongly recommend anyway to stop using abstract namespace AF_UNIX sockets,
-as they bring very little benefit these days.
-If your package uses them
-please consider moving them into the file system
-into a subdirectory in `+/run+` (system services)
-or `+$XDG_RUNTIME_DIR+` (user services).
-
-* This also disconnects the AF_NETLINK and AF_AUDIT socket families from the host.
-For services requiring auditing,
-that need to subscribe to network configuration changes,
-or want to subscribe to hardware devices coming and going (udev)
-`+PrivateNetwork?=yes+` cannot be used hence.
-
-For further details see the
-https://www.freedesktop.org/software/systemd/man/systemd.exec.html[systemd.exec(5)] man page.
-
-[#packaging]
-== Packaging
-
-[#packaging_filesystem]
-=== Filesystem locations
-
-systemd unit files *must* be shipped in either `+%{_unitdir}+` or `+%{_userunitdir}+`,
-for system services and user session services, respectively.
-Unit drop-ins *must* be shipped in appropriate sub-directories of these two directories.
-Unit files and drop-ins *must* be world-readable (i.e. mode `+0644+`)
-and *must not* be marked as `%config` or `%config(noreplace)`.
-
-The `+%{_unitdir}+` and `+%{_userunitdir}+` macros
-are defined in the `+systemd-rpm-macros+` package,
-so something like this is required for them to be available:
-
-....
-BuildRequires: systemd-rpm-macros
-....
-
-[#packaging_unit_files_in_scriptlets]
-=== Unit files in spec file scriptlets
-
-Information on proper handling of unit files in spec file scriptlets
-can be found here:
-xref:Scriptlets.adoc#_systemd[Scriptlets#Systemd].
-
-[#packaging_tmpfiles_d]
-=== Tmpfiles.d
-
-tmpfiles.d is a service provided systemd
-for managing temporary files and directories for daemons.
-For more information on how to use Tmpfiles.d in Fedora Packages,
-please see:
-xref:Tmpfiles.d.adoc[Tmpfiles.d].
-
-[#why_dont_we]
-== Why don't we....
-
-* Start the service after installation?
-
-Installations can be in changeroots,
-in an installer context,
-or in other situations where you don't want the services autostarted.
diff --git a/guidelines/modules/ROOT/pages/Tcl.adoc b/guidelines/modules/ROOT/pages/Tcl.adoc
deleted file mode 100644
index 8b2dc4a..0000000
--- a/guidelines/modules/ROOT/pages/Tcl.adoc
+++ /dev/null
@@ -1,129 +0,0 @@
-= Tcl packaging guidelines
-
-These conventions apply to Tcl packages in Fedora 9 and later. There are some aspects of Tcl in Fedora 7 and Fedora 8 that will conflict with these guidelines.
-
-== Naming Conventions
-
-The name for all Tcl/Tk extensions must be prefixed with `+tcl-+`. This rule applies even for Tcl/Tk packages that are already prefixed with `+tcl+` in the name (see examples below). An optional `+Provides: foo+` is recommended to allow selecting the package based on the upstream name, as long as the upstream name is not excessively generic and does not conflict with an existing package name. Tk extensions have the option of adding additional Provides: with the prefix `+tk-+`. +
-Examples:
-
-....
-Name: tcl-bwidget
-Provides: bwidget = %{version}-%{release}, tk-bwidget = %{version}-%{release}
-....
-
-....
-Name: tcl-tclxml
-Provides: tclxml = %{version}-%{release}
-....
-
-....
-Name: tcl-thread
-....
-
-The exception to this naming rule are existing packages that provide both an extension and a shell, such as `+expect+`. However, note that providing a shell is strongly discouraged (see below).
-
-== Applications
-
-Tcl and Tk applications *must* use a non-versioned interpreter name in shebang line. This is to prevent any unnecessary dependency on the version of the interpreter being used. Most dependencies are with specific Tcl extensions, not the command line applications. Nevertheless, if an application does require a specific version of Tcl, it should use the standard Tcl package system to express this, as well as an explicit `+Requires: tcl(abi) = 8.x+` in the spec file.
-
-Bad:
-
-....
-#!/usr/bin/tclsh8.5
-....
-
-Good:
-
-....
-#!/usr/bin/tclsh
-package require -exact Tcl 8.5
-....
-
-The same rules apply for Tk applications. The non-versioned `+wish+` interpreter name *must* be used.
-
-== Extensions
-
-Since Fedora 9, `+%{_libdir}+` and `+%{_datadir}+` have been removed from the search path to optimize package loading times. Instead, Tcl extension packages *must* be installed in `+%{_datadir}/tcl8.x+` if they are noarch packages containing only Tcl code, or `+%{_libdir}/tcl8.x+` if they are arch-specific extensions containing shared libraries. Note that most Tcl extensions are not configured do install in these directories out of the box, and may need to use additional configure switches, patches, or script code in `+%install+` to move the files to the correct location.
-
-Both arch-specific and `+noarch+` Tcl extensions *must* use
-
-....
-Requires: tcl(abi) = 8.6
-....
-
-to indicate which Tcl version (8.5 in F19 and F20, 8.6 in F21+) they were built against. This is necessary because the guidelines below require extensions to be installed into tcl-versioned directories, which are only used by a single version of Tcl. This does impose an inconvenience that all arch-specific and noarch extensions will need to be rebuilt for a new minor version of Tcl, but since new Tcl minor versions only appear once every few years, this should not be such a problematic inconvenience.
-
-=== noarch packages
-
-The following macros *must* be used at the top of the spec file to determine the correct installation paths:
-
-....
-%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
-%{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}}
-....
-
-In order for the macros to work, the package must also `+BuildRequires: tcl+` either directly, or indirectly with `+BuildRequires: tcl-devel+`
-
-Merely adding the `+%{tcl_sitearch}+` and `+%{tcl_sitelib}+` is not enough to ensure that the packages get installed into the correct location. Most Tcl extensions will install into `+%{_libdir}+` by default. There are two ways to change this. For most `+noarch+` packages, you can use the `+--libdir+` and `+--datadir+` configure switches to change the installation directory:
-
-....
-%configure --libdir=%{tcl_sitelib} --datadir=%{tcl_sitelib}
-....
-
-For `+noarch+` packages that aren't fixed by using `+--libdir+`, you can simply move the installation directory in the `+%install+` section of the spec file.
-
-....
-%install
-rm -rf $RPM_BUILD_ROOT
-make install DESTDIR=$RPM_BUILD_ROOT
-install -d $RPM_BUILD_ROOT%{tcl_sitelib}
-mv $RPM_BUILD_ROOT%{_datadir}/foobar%{version} $RPM_BUILD_ROOT%{tcl_sitelib}/foobar%{version}
-....
-
-It may also be acceptable to patch upstream's `+configure+` script and `+Makefile+` to add additional flexibility for the install directory, but the packager is not required to do this.
-
-=== arch-specific packages
-
-The following macros *must* be used at the top of the spec file to determine the correct installation paths:
-
-....
-%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
-%{!?tcl_sitearch: %global tcl_sitearch %{_libdir}/tcl%{tcl_version}}
-....
-
-In order for the macros to work, the package must also `+BuildRequires: tcl+` either directly, or indirectly with `+BuildRequires: tcl-devel+`
-
-While `+%{tcl_sitearch}+` is a symlink to `+%{tcl_sitelib}+` in Fedora 8 and earlier, in Fedora 9 it is an actual directory.
-
-The `+--libdir+` flag for the configure script can often be used to set the correct installation directory:
-
-....
-%build
-%configure --libdir=%{tcl_sitearch}
-....
-
-For most arch-specific packages, the `+--libdir+` flag for the configure script is also used to locate tclConfig.sh. Some of these arch-specific packages will break if `+--libdir+` is redirected to `+%{tcl_sitearch}+`. For packages that can't handle alternate values for `+--libdir+`, you can simply move the installation directory in the `+%install+` section of the spec file:
-
-....
-%install
-make install DESTDIR=$RPM_BUILD_ROOT
-install -d $RPM_BUILD_ROOT%{tcl_sitearch}
-mv $RPM_BUILD_ROOT%{_libdir}/foobar%{version} $RPM_BUILD_ROOT%{tcl_sitearch}/foobar%{version}
-....
-
-Arch-specific packages can be generally grouped into three categories: those that provide a shell, those that provide a fooConfig.sh file and a shared library for linking, and those that only provide a shared library for dlopen().
-
-*No shells:*
-Very few Tcl extension packages provide a shell. Providing a shell for an extension is frowned upon. The extension's shared library can be dynamically loaded into a Tcl interpreter through the standard `+package require ...+` mechanism without providing a shell that automatically loads the shared library. The exceptions to this rule are the shells that are commonly expected to be present on a system, including Tk (wish) and Expect (expect, expectk).
-
-*-devel subpackage for fooConfig.sh:*
-Some arch-specific Tcl extensions provide a shared library and a corresponding `+fooConfig.sh+` file with instructions for linking against the library. The shared library for such packages *must* be installed into %\{_libdir} so that it can be found at runtime by applications that link against it. Unfortunately, the pkgIndex.tcl file in the package directory often references the shared library with a relative path. There are two ways to fix this. First, the maintainer can choose to keep the installation directory as %\{_libdir}, and make a symlink to %\{tcl_sitearch}. Second, the maintainer can choose to patch the pkgIndex.tcl file to contain an appropriate path to the shared library. Either solution is acceptible.
-
-`+fooConfig.sh+` files must be placed in a -devel subpackage. This may require some sed magic to modify `+fooConfig.sh+` so that the paths to the libraries and headers are still correct.
-
-*No dlopen()'d libraries in %\{_libdir}:*
-If the extension does *not* provide a `+fooConfig.sh+` file, then the shared library *must not* be installed directly in `+%{_libdir}+`, but in the package-specific installation directory in `+%{tcl_sitearch}+` instead. This may require a patch to update the extension's `+pkgIndex.tcl+` file to look for the shared library in the correct location.
-
-*Stubs are ok if put in -devel subpackage:*
-Some Tcl extensions provide a static 'stub' library. Stub libraries are a Tcl-ism to provide version-independent dynamic linking on a variety of platforms. These are not normal static libraries that provide the library's actual functionality, but instead provide a level of indirection pointing to the shared library. These stub libraries do not have the same static linking issues that are generally frowned upon in Fedora, and thus are acceptable. If a package provides such a stub library, it must be placed in a -devel subpackage. More information on stubs can be found on the Tcl wiki: https://wiki.tcl-lang.org/page/Stubs
diff --git a/guidelines/modules/ROOT/pages/Tmpfiles.d.adoc b/guidelines/modules/ROOT/pages/Tmpfiles.d.adoc
deleted file mode 100644
index 93032b8..0000000
--- a/guidelines/modules/ROOT/pages/Tmpfiles.d.adoc
+++ /dev/null
@@ -1,87 +0,0 @@
-= Tmpfiles.d
-
-== Overview
-
-tmpfiles.d is a service for managing temporary files and runtime directories for daemons. In this guideline we mainly concentrate on how it is used to populate `+/run+` and `+/run/lock+`. Since `+/run+` is a `+tmpfs+` filesystem, it and its contents must be recreated on every reboot. For files intended to be created there, this should normally not pose any problems. However, directories will often need to be created ahead of time. This is best done using the tmpfiles.d mechanism.
-
-== tmpfiles.d configuration
-
-Asking the tmpfiles.d mechanism to create directories for you just involves dropping a file into `+%{_tmpfilesdir}+`. You will need a build dependency on systemd-rpm-macros in order to make use of this macro.
-
-For example, if the package needs a few directories to be created in `+/run+` in order for it to run, the packager needs to create a file named `+%{name}.conf+` that is installed as `+%{_tmpfilesdir}/%{name}.conf+`. The file has one or more lines of the following format:
-
-....
-d /run/NAME PERM USER GROUP -
-....
-
-The format of the line is as follows:
-
-* `+d+` specifies that a directory is to be created if it doesn't exist. You can use a different type specifier if you need it. See `+man tmpfiles.d+` for possible values.
-* `+/run/NAME+` is the filesystem path to create.
-* `+PERM+` are the permissions (in the 4-digit octal format) to apply to the directory when it is created.
-* `+USER+` is the name of the owner of the directory.
-* `+GROUP+` is the name of the group of the directory.
-* `+-+` specifies that aging should not be applied to the contents of the directory. Aging is a mechanism for automated cleanup of files that were not used for a specified length of time. This is mostly useful for directories such as /tmp and is seldom used by packages. Feel free to use aging if it is appropriate for your directory.
-
-An example:
-
-....
-d /run/mysqld 0755 mysql mysql -
-....
-
-Information on other options is available on the https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html[tmpfiles.d man page] should you need to do something more advanced.
-
-== Example spec file
-
-In the spec file, the packager needs to install the tmpfiles.d conf file into the `+%{_tmpfilesdir}+` directory and also make sure the directory is included in the rpm.
-
-[source, rpm-spec]
-----
-# For the _tmpfilesdir macro.
-BuildRequires: systemd-rpm-macros
-
-# tmpfiles.d configuration for the /run directory
-Source1:  %{name}-tmpfiles.conf
-[...]
-
-%install
-mkdir -p %{buildroot}%{_tmpfilesdir}
-install -m 0644 %{SOURCE1} %{buildroot}%{_tmpfilesdir}/%{name}.conf
-
-# This may not be needed if the upstream's install script creates the directories
-# Make sure permissions are correct
-install -d -m 0755 %{buildroot}/run/%{name}/
-
-# A bit contrived as most packages will either create a subdirectory or a single file.  Not both
-# Make sure permissions are correct
-touch %{buildroot}/run/%{name}.pid
-chmod 0644 %{buildroot}/run/%{name}.pid
-[...]
-
-%files
-# Use %attr() if needed to change ownership of these two items
-%dir /run/%{name}/
-%verify(not size mtime md5) /run/%{name}.pid
-%{_tmpfilesdir}/%{name}.conf
-----
-
-`+%{_tmpfilesdir}+` expands to `+%{_prefix}/lib/tmpfiles.d+` which is the location that the package's default tmpfile creation scripts should install into. `+%{_tmpfilesdir}/%{name}.conf+` is *not* marked as a `+%config+` file because it is not supposed to be edited by administrators. Administrators can override the package's `+%{name}.conf+` by placing an identically named file in `+/etc/tmpfiles.d/+`, but this should very rarely be needed.
-
-Files (*not directories*) that the program places directly into `+/run+` are listed in the `+%files+` section as `+%verify(not size mtime md5)+` so that rpm knows the file must exist as part of this package but will not complain when the file contents change. Files placed in the subdirectories may be listed the same way or omitted entirely as the files will be cleaned up on every reboot.
-
-== Why not create the directories with XXXXXX instead?
-
-There are multiple ways to try creating the directories but most suffer some disadvantage that tmpfiles.d addresses:
-
-=== Have the daemon create the directory when it starts up
-
-Many times, daemons run as an unprivileged user who would not be allowed to create new directories directly into `+/run+`.
-If the daemon does not drop privileges, then you can patch it to create the files and directories when the daemon starts and submit the patch upstream.
-
-=== Have the init script create the directory when it starts up the daemon
-
-Since the init script is run by root, before the daemon drops privileges, why not create the directories there?
-
-* This code would need to be implemented in every init script packaged. Using tmpfiles.d we can cut down on the number of places we have to put code like this.
-* Having to add the mkdir to the systemd unit files when tmpfiles.d is already in place introduces the need to run shell code for that init script. Systemd is no longer able to handle starting the daemon by itself which slows things down. The shell code also introduces imperative constructs into the otherwise declarative structure which is nice to avoid.
-* Properly labelling the created directories is done automatically by the tmpfiles.d mechanism but would have to be manually done by the init script.
diff --git a/guidelines/modules/ROOT/pages/Tree-sitter.adoc b/guidelines/modules/ROOT/pages/Tree-sitter.adoc
deleted file mode 100644
index fafe34c..0000000
--- a/guidelines/modules/ROOT/pages/Tree-sitter.adoc
+++ /dev/null
@@ -1,51 +0,0 @@
-= Packaging of Tree-sitter parsers
-
-== Macros
-
-The macros in package `tree-sitter-srpm-macros` can do most of the work
-for you.
-
-=== Specifying the build system
-
-Declare that this is a Tree-sitter parser with:
-
-[source,spec]
-----
-BuildSystem: tree_sitter
-----
-
-The `%prep`, `%conf`, `%generate_buildrequires`, `%build`, `%install`
-and `%check` sections will all be provided for you.
-
-This requires RPM version 4.20 (i.e., Fedora 41) or greater.
-
-=== Defining packages and their contents
-
-Generate `%package` and `%files` sections for the subpackages built from your package:
-
-[source,spec]
-----
-%{tree_sitter -l language-name}
-----
-
-Here, _language-name_ is the human-friendly name(s) of the Language
-parser(s) provided by this package, to be mentioned in the package
-summaries and descriptions.
-
-== Example spec file
-
-[source,spec]
-----
-Name:           tree-sitter-typescript
-Version:        0.21.2
-Release:        %autorelease
-License:        MIT
-URL:            https://github.com/tree-sitter/%{name}
-Source:         %{url}/archive/v%{version}/%{name}-%{version}.tar.gz
-BuildSystem:    tree_sitter
-
-%{tree_sitter -l %{quote:TypeScript and TSX}}
-
-%changelog
-%autochangelog
-----
diff --git a/guidelines/modules/ROOT/pages/UnownedDirectories.adoc b/guidelines/modules/ROOT/pages/UnownedDirectories.adoc
deleted file mode 100644
index b322c01..0000000
--- a/guidelines/modules/ROOT/pages/UnownedDirectories.adoc
+++ /dev/null
@@ -1,116 +0,0 @@
-= Unowned Directories
-
-The term "unowned directory" (or "orphaned directory") refers to a packaging mistake where these three things happen:
-
-* a package includes files within a directory it creates, but *not* the directory itself
-* none of the package's dependencies provide the directory either
-* the directory belongs to your package and does not belong to any core package or base filesystem package that is considered essential/fundamental to any Fedora System.
-
-== Issues
-
-Unowned directories can cause the following problems.
-
-=== Inaccessible Directories
-
-A restrictive superuser umask during package installation can create inaccessible directories when installed using the RPM Package Manager older than 4.4.2.3. Fedora 9 and RHEL 5.3 are the first to use RPM 4.4.2.3 which sets umask 0022 always. On platforms with older versions of RPM if the superuser does this:
-
-`+ umask 077+` +
-`+ yum update+` +
-`+ [or]+` +
-`+ rpm -ivh PACKAGE+`
-
-Unowned directories within the updated or installed packages will only be readable and executable by root. This prevents other users from using the files within those directories.
-
-This causes run-time problems for users. For example, unreadable subdirs below %_libdir disable plugins. Unreadable subdirs below %_datadir prevent application data, help texts, and graphics from being accessed.
-
-Several sorts of users fix such permission problems with chmod instead of taking the time to report it as a bug. It is common belief that such bugs are so obvious they would be found by the package maintainer or will be reported by other users.
-
-=== Directories not Removed
-
-Upon uninstalling the package (or upgrading to another version), the old directory is not removed from the file system because it does not belong in the package in the RPM database.
-
-Especially if directories contain a version number, they clutter up the file system with every update which doesn't remove old directories.
-
-=== Directories cannot be Verified
-
-Unowned/orphaned directories cannot be checked with rpm -V and not with rpm -qf either.
-
-=== ./configure Scripts can Fail
-
-Upstream source tarball configuration can fail, because it detects the presence of an old but empty versioned header directories or because it is trying to use multiple versioned directories instead of just the latest valid one.
-
-== Tools to Help
-
-It's easy to find unowned directories with `+rpmls+` from rpmdevtools or `+rpm -qlv+`. Just a bit of carefulness is needed to not include core filesystem directories, such as %_bindir, %_libdir (and obvious others, e.g. from the "filesystem" pkg) which don't belong into your package.
-
-== Common Mistakes
-
-Here are some examples of common packaging mistakes in spec %files lists to avoid
-
-=== Wildcarding Files inside a Created Directory
-
-==== Unversioned
-
-----
-%{_datadir}/foo/*
-----
-
-This includes everything _in_ "foo", but not "foo" itself. "rpm -qlv pkgname" will show a missing drwxr-xr-x entry for "foo". Correct would be:
-
-----
-%{_datadir}/foo/
-----
-
-to include the directory _and_ the entire tree below it.
-
-==== Versioned
-
-----
-%{_docdir}/%{name}-%{version}/*
-%{_includedir}/%{name}-%{version}/*.h
-----
-
-This is the same as the unversioned scenario with the addition that every time the package is upgraded to a new version the old directory will remain on the filesystem. Correct would be:
-
-----
-%{_docdir}/%{name}-%{version}/
-%dir %{_includedir}/%{name}-%{version}
-%{_includedir}/%{name}-%{version}/*.h
-----
-
-=== Forgetting to Include a Toplevel Directory
-
-----
-%dir %{_libdir}/foo-2/fu
-%dir %{_libdir}/foo-2/bar
-%{_libdir}/foo-2/fu/*.so
-%{_libdir}/foo-2/bar/config*
-----
-
-Here it is an attempt at including the directories explicitly with the %dir macro. However, while "bar" is included, "foo-2" is not. Typically packagers run into that mistake if all installed files are stored only in subdirs of the parent "foo-2" directory. Correct would be:
-
-----
-%dir %{_libdir}/foo-2
-%dir %{_libdir}/foo-2/fu
-%dir %{_libdir}/foo-2/bar
-%{_libdir}/foo-2/fu/*.so
-%{_libdir}/foo-2/bar/config*
-----
-
-==== Only Including Files
-
-----
-%{_datadir}/%{name}/db/raw/*.db
-%{_datadir}/%{name}/pixmaps/*.png
-----
-
-Here only specific data files are included, and all 4 directories below %_datadir are unowned. Correct would be:
-
-----
-%dir %{_datadir}/%{name}
-%dir %{_datadir}/%{name}/db
-%dir %{_datadir}/%{name}/db/raw
-%dir %{_datadir}/%{name}/pixmaps
-%{_datadir}/%{name}/db/raw/*.db
-%{_datadir}/%{name}/pixmaps/*.png
-----
diff --git a/guidelines/modules/ROOT/pages/Unversioned_shared_objects.adoc b/guidelines/modules/ROOT/pages/Unversioned_shared_objects.adoc
deleted file mode 100644
index 0686479..0000000
--- a/guidelines/modules/ROOT/pages/Unversioned_shared_objects.adoc
+++ /dev/null
@@ -1,114 +0,0 @@
-include::{partialsdir}/attributes.adoc[]
-
-= Unversioned Dynamic Shared Objects
-
-The standard policy
-is to have versioned SONAMES
-for all dynamic shared objects (DSO).
-Packagers ``SHOULD`` work with upstreams
-that do not have versioned SONAMES
-to enable this capability.
-This is a hard requirement
-if the DSO is being linked
-between different software.
-
-This policy
-helps to ensure ABI compatibility
-when DSOs are dynamically linked
-between different software.
-
-== When Are Unversioned Dynamic Shared Objects Acceptable
-
-There are a few conditions
-that need to exist in which DSOs are allowed to remain unversioned.
-
-* The DSO ``MUST NOT`` be visible
-to the dynamic linker
-(i.e. the DSO does not show up in ``ldconfig -p`` output)
-
-* The DSO ``MUST`` be located in a private directory
-(i.e. not located directly in /usr/lib[64] or in another directory listed as a library path for the linker)
-
-* The DSO ``MUST NOT`` be linked against and is loaded at runtime
-by the implementing application 
-(i.e. ``dlopen()``)
-
-If these conditions are met,
-the unversioned DSOs
-do not need to be placed in a -devel package.
-
-== Implementation Details
-
-Listed below is information
-for each known use-case for unversioned DSOs.
-Evaluate if your situation matches any of these
-and ask for any clarification
-by opening a ticket with the {packaging-committee}.
-
-=== Vulkan
-
-The https://vulkan.org[Vulkan] ecosystem
-continues to grow in capabilities and adoption.
-One of the core concepts
-is the https://docs.vulkan.org/guide/latest/loader.html[Vulkan Loader].
-This component is responsible for initializing the stack
-and includes loading unversioned DSOs,
-called Drivers and Layers.
-
-Vulkan Drivers need to be visible to the default loader
-and are a special exception.
-
-Drivers have the following requirements:
-
-* The DSO ``SHOULD`` be located in a private directory in /usr/lib[64]
-(i.e. `+%{_libdir}/%{name}/driver+`)
-
-* The directory ``SHOULD`` be added to the loader path using a ``ld.conf.d`` configuration
-(i.e. `+%{_sysconfdir}/ld.conf.d/%{name}.conf+` definition)
-
-Vulkan Layers are loaded by configuration as defined by the Vulkan Loader specification.
-
-Layers have the following requirements:
-
-* The DSO ``MUST`` be located in a private directory in /usr/lib[64]
-(i.e. `+%{_libdir}/%{name}/layer+`)
-and loaded by configuration
-
-=== OpenXR
-
-The https://www.khronos.org/openxr/[OpenXR] ecosystem
-enables users to run XR applications built against the SDK.
-One of the core concepts
-is the https://registry.khronos.org/OpenXR/specs/1.1/loader.html[OpenXR Loader].
-This component is responsible for initializing the stack
-and includes loading unversioned DSOs,
-called Runtimes and Layers.
-
-OpenXR Runtimes are loaded by configuration as defined by the OpenXR Loader specification.
-
-Runtimes have the following requirements:
-
-* The DSO ``MUST`` be located in a private directory in /usr/lib[64]
-(i.e. `+%{_libdir}/%{name}/runtime+`)
-
-* The directory ``SHOULD`` be added to the loader path using a ``ld.conf.d`` configuration
-(i.e. `+%{_sysconfdir}/ld.conf.d/%{name}.conf+` definition)
-
-OpenXR Layers are loaded by configuration as defined by the OpenXR Loader specification.
-
-Layers have the following requirements:
-
-* The DSO ``MUST`` be located in a private directory in /usr/lib[64]
-(i.e. `+%{_libdir}/%{name}/layer+`)
-and loaded by configuration
-
-=== Other Cases
-
-An example of another case
-is an unversioned DSO
-that is loaded at runtime
-within the same application.
-This allows an application
-to load an optional feature, ship modular capabilities,
-or otherwise ``dlopen()`` it's own capabilities.
-These are allowed as long as the main requirements are met.
diff --git a/guidelines/modules/ROOT/pages/UsersAndGroups.adoc b/guidelines/modules/ROOT/pages/UsersAndGroups.adoc
deleted file mode 100644
index 7ea4828..0000000
--- a/guidelines/modules/ROOT/pages/UsersAndGroups.adoc
+++ /dev/null
@@ -1,236 +0,0 @@
-= Users and Groups Guidelines
-
-This guideline is for packaging cases
-that require creation of users and groups.
-
-== Basic premise for users
-
-In designing these guidelines it was accepted
-that individual sites will have a need
-to customize the allocation of UIDs and GIDs
-to their particular systems.
-For instance, if they have both Debian and Fedora installs
-or if they've already allocated user accounts
-in the range that we use for system accounts
-and need to place system accounts elsewhere.
-Therefore, the methods that these guidelines advocate
-had to be adaptable
-so that local sysadmins could make our packages
-use the UIDs and GIDs that they desired at their site.
-
-The guidelines provide two options:
-letting each individual system allocate UID and GID values individually
-or using a "soft static" allocation
-that attempts to allocate UIDs and GIDs consistently.
-In either case,
-if the username or groupname being created by the package
-already exists on the system
-the package will use that instead of creating a new one.
-This allows the local system administrator
-to pre-allocate the UIDs and GIDs
-for particular usernames and groupnames
-in order to set them to a particular value for their site.
-
-=== Methods of pre-allocating
-
-There are many ways to pre-allocate the UIDs and GIDs.
-Sites that only want to customize the UIDs and GIDs
-of a few nonessential services may write a script
-to create the entries with `+useradd+` and `+groupadd+`
-and install our package afterwards.
-
-Sites that want to pre-allocate accounts
-that are needed during an unattended kickstart install
-have trickier problem.
-One way for them to accomplish their goals
-is to create a customized version of the `+setup+` package
-with the desired users and groups
-along with their chosen UID/GID mappings
-in the `+/etc/passwd+`, `+/etc/shadow+`, and `+/etc/group+` files.
-Then they make sure the install transaction uses that package
-instead of the vanilla distro one
-(by versioning their setup package higher than ours
-(for instance, with an epoch)
-and putting it in a local repo they include
-when installing or replacing our setup package
-with their own in a local mirror of the packages that they are installing from).
-Since setup is at the top of the dependency tree,
-it will be installed before any package
-which needs to use the UIDs and GIDs that are defined in it.
-
-TIP: *Using LDAP to preallocate*:
-Sites with LDAP or other network authentication systems
-may want to use those for pre-allocating their system accounts sitewide.
-Such sites should make sure their infrastructure is robust
-and includes suitable local caching of the system accounts.
-Without suitable local caching,
-a computer that becomes disconnected from the network
-may not be able to start essential services
-because the computer is unable to resolve a username or groupname
-to a proper UID or GID.
-
-=== Known caveat of the pre-allocation strategy
-
-The practice of using existing users and groups
-if their symbolic names (usernames and groupnames) already exists on the system
-lets the system administrator customize the UIDs and GIDs as they please.
-However, it has one drawback that system admins should be aware of.
-If an unrelated account has already been created
-that uses those usernames and groupnames
-the package will make use of those accounts.
-
-As an example, say that you are installing the mailman package
-which wants to create the `+mailman+` user and group
-so that the private mailing list archives can be owned by that user and group on disk.
-One of your local users already has the local username `+mailman+`.
-When the mailman package is installed,
-it will detect that there is already a `+mailman+` user
-and use that account for owning its private archives.
-The local user who owns the mailman account
-would then be able to read those private archives.
-
-At the moment, there is no strategy for the packagers to counteract this.
-It is up to the site system administrators to keep track of and remove conflicts
-for the user and group names used by their users
-and those used by the packages they are using.
-
-== Allocation Strategies
-
-We have two methods for creating users and groups:
-Dynamic and Soft Static.
-
-Any package can use dynamic allocation;
-it is especially appropriate for packages
-that use separate identities only for privilege separation
-and don't create any files owned by that group/user account.
-Because of the limited number of soft static UIDs and GIDs available,
-it is better to use dynamic allocation if in doubt.
-
-Soft static allocation ensures that multiple independently installed systems
-use the same UID and GID values;
-either UID and GID values allocated by Fedora
-or values that were optionally pre-allocated by the system administrator.
-Don't use soft static allocation unnecessarily
-as the number of available values is limited.
-Soft static allocation is only appropriate for packages
-where the UID or GID values are shared between computers.
-For instance, if the package creates files with the assigned UID or GID
-that are likely to be shared over NFS.
-Soft static allocation *MUST* be evaluated by the FPC.
-See the paragraph in the
-link:#_soft_static_allocation[ soft static section]
-for details the FPC will want.
-
-In some cases it is desirable to create only a group without a user account.
-Usually this is because there are some system resources
-to which we want to control access by using that group
-and a separate user account would add no value.
-Examples of common such cases include (but are not limited to)
-games whose executables are setgid
-for the purpose of sharing high score files or the like,
-and/or software that needs exceptional permissions to some hardware devices
-and it wouldn't be appropriate to grant those to all system users
-nor even only those logged in on the console.
-In these cases, apply only the `+groupadd+` parts of the below recipes.
-
-=== Dynamic allocation
-
-To create system users and groups in packages using dynamic allocation,
-the package shall install a `sysusers.d/<package-name>.conf` file.
-If it is not provided by the upstream,
-the maintainer *should* provide one either as a separate `+Source+`
-or otherwise create it during the package build.
-
-For example for the `munge` package, this file may contain:
-```
-#Type Name   ID  GECOS                        Home directory  Shell
-u     munge  -   "Runs Uid 'N' Gid Emporium"  /run/munge      -
-```
-
-(The shell is not specified, so the default of `nologin` shall be used.)
-
-When a package with a sysusers.d file is built,
-a virtual `Provides` for `+user(…)+` and `+group(…)+` is automatically generated.
-When `rpm` installs a package with such `Provides`,
-it shall create the users and groups according to those definitions.
-
-Use `+rpm -q --qf='[%{SYSUSERS}\n]' …+` to view the definitions of users and groups
-decoded from the virtual `Provides`.
-
-=== Creation of users and groups with scriptlets
-
-For Fedora releases before 42,
-manual creation of users and groups is required.
-
-The sysusers file must be a separate `Source` file.
-
-In the specfile, add a BuildRequires for systemd-rpm-macros, install the sysusers file,
- use the `%sysusers_create_compat` macro to consume it in the `%pre` section
-(in this example the sysusers config file is `Source3` of the specfile), and the
-`%sysusers_requires_compat` macro to specify the runtime dependencies for the `%pre`
-section:
-```
-[...]
-BuildRequires:  systemd-rpm-macros
-%{?sysusers_requires_compat}
-
-[...]
-%install
-install -p -D -m 0644 %{SOURCE3} %{buildroot}%{_sysusersdir}/munge.conf
-
-[...]
-%pre
-%sysusers_create_compat %{SOURCE3}
-
-[...]
-%files
-%{_sysusersdir}/munge.conf
-[...]
-```
-
-This form is compatible with Fedora 42+,
-and the same spec file may be used for older and newer releases.
-In F42+, the `%sysusers_requires_compat` and `%sysusers_create_compat`
-macros will evaluate as empty.
-
-=== Soft static allocation
-
-To allocate a UID and/or GID,
-file a ticket https://pagure.io/packaging-committee/new_issue[here]
-for the FPC to evaluate.
-If the FPC finds that your package needs a soft static UID or GID,
-they will approve your request
-and pass it on to the maintainers of the `+setup+` package for implementation.
-Because the number of UIDs and GIDs is limited,
-you need to justify your package's need for a soft static uid in the FPC ticket.
-Explain how the uids and gids are being shared between computers.
-If applicable, also explain why the program can't be adapted
-to use symbolic names (username and groupname) instead.
-If a specific UID or GID should be used,
-please mention it and why
-(for instance, it is the one used by upstream
-or the one used by other distributions).
-We will try to accommodate on a first-come-first serve basis
-if the UID/GID is available from within the Fedora system UID/GID range.
-
-To create users and groups in packages with an allocated UID/GID,
-follow the steps in the dynamic allocation section above,
-but add the UID or GID in the `ID` column.
-
-=== Sharing of users or groups between packages
-
-The package that provides the definition of the user or group account
-has automatically-generated virtual `Provides`.
-Other packages which want to ensure that users or groups exist,
-*may* use `Requires` on the user or group names.
-
-For example, `+Requires: user(mock)+` or `+Requires: group(man)+`.
-
-`rpm` automatically creates weak dependencies (`Recommends`)
-for packages which contain files owned by users and groups.
-In the future, those depencencies will be changed to `Requires`.
-
-=== List of statically allocated UID/GID and corresponding package
-
-The list of statically allocated accounts is maintained in the `setup` package:
-https://src.fedoraproject.org/rpms/setup/blob/rawhide/f/uidgid[uidgid].
diff --git a/guidelines/modules/ROOT/pages/Versioning.adoc b/guidelines/modules/ROOT/pages/Versioning.adoc
deleted file mode 100644
index 2f8a32c..0000000
--- a/guidelines/modules/ROOT/pages/Versioning.adoc
+++ /dev/null
@@ -1,510 +0,0 @@
-include::{partialsdir}/versions.adoc[]
-
-= Versioning Guidelines
-
-Fedora's package versioning scheme
-encompasses both the `+Version:+`
-and `+Release:+` tags, as well as `+Epoch:+`.
-The overriding goal is to provide sequences of packages
-which are treated as updates by RPM's version comparison algorithm
-while accommodating varied and often inconsistent upstream versioning schemes.
-
-The `+Version:+` field contains the upstream project version,
-and the `+Release:+` field specifies the downstream release number.
-
-== Some definitions
-
-Note that upstreams may each have their own terminology
-and it is in general impossible to define these terms with complete generality.
-For some upstreams, every commit is itself considered a version.
-Some upstreams never make releases,
-instead just letting users take whatever is in the code repository at any given time.
-
-release version::
-  A version of the software which upstream has decided to release.
-  The act of releasing the software can be as simple as adding a git tag.
-  This includes so-called "point releases" or "patchlevels" which some upstreams make,
-  since those are actually assigned versions and released.
-
-snapshot::
-  An archive taken from upstream's source code control system
-  which is not associated with any release version.
-
-prerelease version::
-  Before a release happens,
-  many upstreams will decide which version that will release will have,
-  and then produce "alphas", "betas", "release candidates",
-  or the like which carry that new version
-  but indicate that the release of that version has not yet been made.
-  These we call prerelease versions.
-  Any snapshots made while upstream is preparing for their release
-  are also considered prerelease versions.
-
-postrelease version::
-  Any version which happens after a particular release is technically "post-release",
-  but before upstream begins making prereleases for the next version,
-  any snapshot is considered a postrelease version.
-
-non-sorting version sequence::
-  A sequence of version strings which is not ordered
-  in the same way that RPM's version comparison function would order it.
-  RPM has a somewhat complicated version comparison function
-  which it will use to determine if a package is "newer".
-  If upstream's idea of what constitutes a "newer" version differs
-  from RPM's implementation then simply using upstream's versions directly
-  will result in updates which don't actually update any packages.
-
-== `+Epoch+` tag
-
-The `+Epoch:+` tag provides the most significant input to RPM's version comparison function.
-If present, it **must** consist of a positive integer.
-It **should only** be introduced or incremented
-when necessary to avoid ordering issues.
-The `+Epoch:+` tag, once introduced to a package,
-**must never** be removed or decreased.
-
-== `+Release+` tag
-
-The `+Release:+` **should** be managed automatically using the `+%autorelease+` macro:
-[source, rpm-spec]
-----
-Release: %autorelease
-----
-
-As described in
-https://fedora-infra.github.io/rpmautospec-docs/autorelease.html[%autorelease documentation],
-the build machinery will
-replace the macro with the number of builds since the last commit that changed the `+Version+` field,
-suffixed with the `%{?dist}` tag.
-This means that a commit that changes `+Version+` automatically gets `Release: 1%{?dist}`,
-and commits after that get `Release: 2%{?dist}`, `Release: 3%{?dist}`, and so on.
-
-Alternatively, the `+Release:+` field **may** be updated manually.
-See xref:Versioning.adoc#traditional-versioning[Traditional versioning
-with part of the upstream version information in the release field].
-
-== Simple versioning
-
-Most upstream versioning schemes are "simple";
-they generate versions like `+1.2.03.007p1+`.
-They consist of one or more version components, separated by periods.
-Each component is a whole number, potentially with leading zeroes.
-The components can also include one or more ASCII letters, upper or lower case.
-The value of a component must *never* be reduced (to a value which sorts lower)
-without a component somewhere to the left increasing.
-Note that the version sequence (`+1.4a+`, `+1.4b+`, `+1.4+`)
-does not meet this criterion,
-as `+4+` sorts lower than `+4b+`.
-The sequence (`+1.4+`, `+1.4a+`, `+1.4b+`) is, however, simple.
-
-This is a very common versioning scheme,
-and the vast majority of software projects use something which works like this.
-
-To package *release versions* of software using this versioning scheme:
-
-* Use the upstream project version verbatim in the `+Version:+` tag.
-  Don't trim leading zeroes.
-
-== Complex versioning
-
-There are several ways in which the simple scheme might not work
-in a particular situation:
-
-* Upstream has never chosen a version;
-  only snapshots are available for packaging.
-* Upstream simply doesn't use a version scheme
-  which orders properly under RPM's version comparison operation.
-* You wish to package a prerelease version
-  (snapshot or otherwise).
-* You wish to package a postrelease snapshot.
-* Upstream was thought to be following one scheme
-  but then changed in a way that does not sort properly.
-* You need to apply a small fix to a release branch of Fedora
-  without updating the newer branches.
-* More than one of the above may apply (lucky you).
-  Follow all of the relevant recommendations below together.
-
-This subsection describes how to modify the upstream project version to be suitable for the `+Version+` field.
-Use of `Release: +%autorelease+` remains unchanged.
-
-=== Handling non-sorting versions with tilde, dot, and caret
-
-The tilde symbol ('`+~+`') is used before a version component which must sort *earlier* than any non-tilde component.
-It is used for any pre-release versions which wouldn't otherwise sort appropriately.
-
-For example, with upstream releases `+0.4.0+`, `+0.4.1+`, `+0.5.0-rc1+`, `+0.5.0-rc2+`, `+0.5.0+`,
-the two "release candidates" should use `+0.5.0~rc1+` and `+0.5.0~rc2+` in the `+Version:+` field.
-
-Bugfix or "patchlevel" releases that some upstream make should be handled using simple versioning.
-The separator used by upstream may need to be replaced by a dot or dropped.
-
-For example, if the same upstream released `+0.5.0-post1+` as a bugfix version,
-this "post-release" should use `+0.5.0.post1+` in the `+Version:+` field.
-Note that `+0.5.0.post1+` sorts lower than both `+0.5.1+` and `+0.5.0.1+`.
-
-The caret symbol ('`+^+`') is used before a version component which must sort *later* than any non-caret component.
-It is used for post-release snapshots, see next section.
-
-IMPORTANT: The caret operator is not supported in RHEL7 which has rpm 4.11.
-If you need to support RHEL7/EPEL7 from the same specfile, use
-<<Traditional versioning with part of the upstream version information in the release field>>
-instead.
-
-=== Snapshots
-
-Snapshots (a version taken from the upstream source control system not associated with a release),
-**must** contain a snapshot information field after a caret (`+^+`).
-The first part of the field ensures proper sorting.
-That field may either be the date in eight-digit "YYYYMMDD" format,
-which specifies the last modification of the source code,
-or a number.
-The packager **may** include up to 17 characters of additional information after the date,
-specifying the version control system and commit identifier.
-The snapshot information field is appended to version field described above,
-possibly including the pre-release and patchlevel information.
-
-One of the following formats should be used for the snapshot information field:
-
-* `+<date>.<revision>+`
-* `+<date><scm><revision>+`
-* `+<number>.<revision>+`
-* `+<number>.<scm><revision>+`
-* `+<scm><date>.<revision>+`
-* `+<scm><number>.<revision>+`
-
-Where `+<scm>+` is a short string
-identifying the source code control system upstream uses
-(e.g. "git", "svn", "hg") or the string "snap".
-The `+<scm>+` string may be abbreviated to a single letter.
-`+<revision>+` is either a short git commit hash, a subversion revision number,
-or something else useful in identifying the precise revision in upstream's source code control system.
-If the version control system does not provide an identifier (e.g. CVS), this part should be omitted.
-A full hash **should not** be used for `+<revision>+`, to avoid overly long version numbers;
-only the first 7 to 10 characters.
-
-For example, if the last upstream release was `+0.4.1+`,
-a snapshot could use `+0.4.1^20200601g01234ae+` in the `+Version:+` field.
-Similarly, if the upstream then makes a pre-release with version `+0.5.0-rc1+`,
-but it is buggy, and we need to actually package two post-pre-release snapshots,
-those shapshots could use `+0.5.0~rc1^20200701gdeadf00f+` and `+0.5.0~rc1^20200702gdeadaeae+`
-in the `+Version:+` field.
-
-Alternatively, those three snapshots could be versioned as
-`+0.4.1^1.git01234ae+`,  `+0.5.0~rc1^1.gitdeadf00f+` and `+0.5.0~rc1^2.gitdeadaeae+`.
-
-Note that `+0.4.1^<something>+` sorts higher than `+0.4.1+`, but lower than both `+0.4.2+` and `+0.4.1.<anything>+`.
-
-=== Upstream has never chosen a version
-
-When upstream has never chosen a version,
-you **must** use `+Version: 0+`.
-"0" sorts lower than any other possible value that upstream might choose.
-If upstream does choose to release "version 0",
-then just set `+Release:+` higher than the previous value.
-(When `%autorelease` is used, this happens automatically.)
-
-=== Upstream uses invalid characters in the version
-
-It's possible that upstream uses characters besides ASCII letters
-(upper and lower case), digits and periods in its version.
-They must be removed and potentially replaced with valid characters.
-Any such alterations **must** be documented in the specfile.
-It is not possible to cover all potential situations here,
-so it is left to the packager
-to alter the upstream versioning scheme consistently.
-
-After altering the version to be free of invalid characters,
-see <<Unsortable versions>> below
-if the modifications,
-when applied to successive releases from upstream,
-will not order properly.
-
-=== Unsortable versions
-
-When upstream uses a versioning scheme that does not sort properly,
-first see if simply inserting a tilde or caret is enough to make the string sortable.
-
-For example, if upstream uses a sequence like `+1.2pre1+`, `+1.2pre2+`, `+1.2final+`,
-then `+1.2~pre1+`, `+1.2~pre2+`, `+1.2_final+` could be used as `+Version+`.
-The underscore ('`+_+`') is a visual separator that does not influence sort order,
-and is used here because "final" does not form a separate version component.
-
-If this is not possible, use something similar to the snapshot version information field described above,
-with the upstream version moved to the second part of the snapshot information field:
-`+<date>.<version>+`.
-
-For example, if upstream releases versions `+I+`, `+II+`, …, `+VIII+`, `+IX+`
-use `+20200101.I+`, `+20200201.II+`, …, `+20200801.III+`, `+20200901.IX+`
-in the `+Version+` field.
-
-=== Upstream breaks version scheme
-
-It is possible that upstream simply adopts a different versioning scheme,
-fails to follow an expected pattern,
-or even simply resets their version to some lower value.
-If none of the above operations can help
-with giving a version which sorts properly,
-or give you a version which sorts lower
-than the packages already in Fedora,
-then you have little recourse but to increment the `+Epoch:+` tag,
-or to begin using it by adding `+Epoch: 1+`.
-At the same time, try to work with upstream
-to hopefully minimize the need to involve `+Epoch:+` in the future.
-
-=== Examples
-
-==== Comparing versions with `rpmdev-vercmp`
-
-When in doubt, verify the sorting with `rpmdev-vercmp` from the `rpmdevtools` package:
-
-```console
-$ rpmdev-vercmp 2~almost^post 2.0.1
-2~almost^post < 2.0.1
-```
-
-==== Simple versioning
-
-[%header]
-|===
-|Upstream version | Version tag | Explanation
-
-|1.0     |1.0         | The first release.
-
-|1.1     |1.1         | An upstream update.
-
-|1.2.1   |1.2.1       | Another upstream update. Extra levels of versioning are OK…
-
-|1.3     |1.3         | …they can come and go without problems.
-|===
-
-In this case the full N-V-R could be e.g. `pkg-1.2.1-1.fc{CURRENTVER}` (immediately after an update)
-or `pkg-1.2.1-5.fc{CURRENTVER}` (after downstream rebuilds with the same upstream version).
-
-[%header]
-|===
-|Upstream version | Version tag | Explanation
-
-| 5.2    | 5.2        | Upstream release.
-
-| 5.2a   | 5.2a       | Upstream introduced a letter to indicate a patch release. You trust upstream to use letters in alphabetical order, so it's OK to use the version as is.
-
-| 5.2b   | 5.2b       | Another patch release after 5.2 — this is not a beta.
-
-| 5.2b.1 | 5.2b.1     | Even this is OK as long as the sequence increases.
-
-| 5.3    | 5.3        | Another upstream release.
-|===
-
-In this case the full N-V-R could be e.g. `pkg-5.2b.1-1.fc{CURRENTVER}`.
-
-==== Complex versioning with a reasonable upstream
-
-[%header]
-|===
-|Upstream version | Version tag | Notes
-
-| 1.0.0-rc1 | `+1.0.0~rc1+` | first prerelease
-
-| 1.0.0-rc2 | `+1.0.0~rc2+` | second prerelease
-
-| 1.0.0     | `+1.0.0+`     | release
-
-| 1.0.1     | `+1.0.1+`     | bugfix release
-
-| 1.0.1-security1 | `+pkg-1.0.1.security1+` | security bufix release
-|===
-
-In this case the full N-V-R could be e.g. `pkg-1.0.0~rc2-42.fc{CURRENTVER}` (if many rebuilds were done).
-
-==== Complex versioning with non-sorting upstream post-release versions
-
-[%header]
-|===
-|Upstream version | Version tag | Notes
-
-| 1.1.0~BETA      | `+1.1.0~BETA+` | this is a prerelease, first beta
-
-| 1.1.0~BETA1     | `+1.1.0~BETA1+` | this is a prerelease, second beta
-
-| 1.1.0~BETA2     | `+1.1.0~BETA2+` | this is a prerelease, third beta
-
-| 1.1.0~CR1       | `+1.1.0~CR1+` | this is a prerelease, candidate release 1
-
-| 1.1.0~CR2       | `+1.1.0~CR2+` | this is a prerelease, candidate release 2
-
-| 1.1.0-1%        | `+1.1.0+` | final release
-
-| 1.1.0-GA1       | `+1.1.0.20201001.GA1+` | post release, GA1
-
-| 1.1.0-CP1       | `+1.1.0.20201011.CP1+` | post release, CP1, after GA1, does not sort properly
-
-| 1.1.0-CP2       | `+1.1.0.20201101.CP2+` | post release, CP2, after CP1
-
-| 1.1.0-SP1       | `+1.1.0.20210101.SP1+` | post release, SP1, after CP2
-
-| 1.1.0-SP1-CP1   | `+1.1.0.20210105.SP1_CP1+` | post release, SP1_CP1, after SP1
-|===
-
-In this case the full N-V-R could be e.g. `pkg-1.1.0.20210105.SP1_CP1-1.fc{CURRENTVER}`.
-
-==== Complex versioning with a pre- and post-release snapshots
-
-[%header]
-|===
-|Upstream version | Version | Notes
-
-| 1.0.0-rc1            | `+1.0.0~rc1+` | First prerelease
-
-| 1.0.0-rc2            | `+1.0.0~rc2+` | Second prerelease
-
-| git commit `f00fabd` | `+1.0.0~rc2^20210101gf00fabd+` | Post-prerelease snapshot
-
-| 1.0.0                | `+1.0.0+`     | A release
-
-| 1.0.1                | `+1.0.1+`     | A bugfix release
-
-| git commit `bbbccc0` | `+1.0.1^20210203gbbbccc0+` or `+pkg-1.0.1^1.gbbbccc0+` | A snapshot
-
-| 1.0.1-security1      | `+1.0.1.security1+` | A security bufix release. From past history we know that the bugfix releases will have sortable versions. If not, we could use '`+<date>.security1+`' instead.
-
-| git commit `abc0202` | `+1.0.1.security1^20210301gabc0202+` or `+pkg-1.0.1.security1^1.gabc0202+` | Another snapshot
-|===
-
-In this case the full N-V-R could be e.g. `pkg-1.0.1.security1^20210301gabc0202-1.fc{CURRENTVER}`.
-
-[#traditional-versioning]
-== Traditional versioning with part of the upstream version information in the Release field
-
-The method described in this section is deprecated, but **may** be used.
-As mentioned in the xref:_handling_non_sorting_versions_with_tilde_dot_and_caret[Handling non-sorting versions with tilde, dot, and caret] section above,
-this method is recommended for packages with complex versioning when supporting RHEL7
-and other systems with old rpm versions.
-
-In this method, `+%autorelease+` is not used, and the `Release` field must be managed manually.
-
-This method for dealing with most pre- and post-release versions and unsortable versions
-involves potentially removing some information from the `+Version:+` tag
-while imposing additional structure onto the `+Release:+` tag.
-There are potentially four fields which comprise
-the structured `+Release:+` tag:
-
-* package release number (`+<pkgrel>+`)
-* extra version information (`+<extraver>+`)
-* snapshot information (`+<snapinfo>+`)
-* minor release bump (`+<minorbump>+`)
-
-The package release number **must** always be present
-while the others may or may not be depending on the situation.
-
-Those items which are present are combined
-(with periods to separate them)
-to construct the final `+Release:+` tag.
-In the usual notation where
-square brackets indicate that an item is optional:
-
-    <pkgrel>[.<extraver>][.<snapinfo>]%{?dist}[.<minorbump>]
-
-The actual values to be used for those three fields are situational
-and are referenced in the sections below.
-Note that your particular situation might not result
-in the use of `+<extraver>+` or `+<snapinfo>+`,
-and in most situations `+<minorbump>+` won't be used at all.
-Simply do not include those which you don't have.
-
-Note that the dist tag is supplied by other portions of the system
-and may in some circumstances contain additional structure,
-including tildes.
-As this is not under the control of the packager,
-that structure is not covered here.
-The packager **must** simply include `+%{?dist}+` verbatim
-as indicated above.
-
-=== Unsortable versions
-
-When upstream uses a versioning scheme that does not sort properly,
-first see if there is any portion which can be removed
-from the right side of the version string
-such that the remainder is sortable.
-This is often possible if upstream uses a sequence like
-("1.2pre1", "1.2pre1", "1.2final").
-If so, use the removed portion as `+<extraver>+` above,
-and the remainder as the package version.
-If this splitting leaves a leading or trailing period in either value,
-remove it.
-
-If this is not possible,
-use Version: 0 and move the _entire_ version string into `+<extraver>+`.
-
-=== Snapshots
-
-All snapshots **must** contain a snapshot information field
-(`+<snapinfo>:+`) in the `+Release:+` tag.
-That field must at minimum consist of the date
-in eight-digit "YYYYMMDD" format.
-The packager **may** include
-up to 17 characters of additional information
-after the date.
-The following formats are suggested:
-
-* `+YYYYMMDD.<revision>+`
-* `+YYYYMMDD<scm><revision>+`
-
-Where `+<scm>+` is a short string
-identifying the source code control system upstream uses
-(e.g. "git", "svn", "hg")
-or the string "snap".
-`+<revision>+` is either
-a short git commit hash,
-a subversion revision number,
-or something else useful in identifying the precise revision
-in upstream's source code control system.
-Obviously if CVS is used,
-no such revision information exists,
-so it would be omitted,
-but otherwise it **should** be included.
-
-=== Prerelease versions
-
-In the `+Version:+` tag,
-use the version that upstream has determined the next release will be.
-For the field of the `+Release:+` tag,
-use a number of the form "0.N"
-where N is an integer beginning with 1
-and increasing for each revision of the package.
-Prerelease versions **must** use
-a `+Release:+` tag strictly less than 1,
-as this is the sole indicator that a prerelease has been packaged.
-
-=== Release and post-release versions
-
-For the `+<pkgrel>+` field of the `+Release:+` tag,
-use an integer beginning with 1
-and increasing for each revision of the package.
-Release and post-release versions **must** use
-a `+Release:+` tag greater than or equal to 1.
-
-=== Rebuilds in older branches using `<minorbump>`
-
-In the situation described in <<Only an old branch needs a change>>,
-you **may** adjust the `+Release+` by appending a number *after* the dist tag,
-creating a E-V-R for F{CURRENTVER} that still compares lower than the one in F{NEXTVER}.
-Set `+<minorbump>+` to an in integer beginning with '1'
-and increase it by one for each minor bump you need to do.
-Remove `+<minorbump>+` once you are able
-to increase the package release normally
-without introducing ordering issues.
-
-=== Examples
-
-Examples of many possible versioning scenarios of traditional versioning
-are available from
-https://fedoraproject.org/wiki/Package_Versioning_Examples[Package Versioning Examples].
-
-
-== Rawhide is allowed to lag temporarily
-
-A package **may** temporarily have a lower EVR in Rawhide
-when compared to a release branch of Fedora
-ONLY in the case where the package fails to build in Rawhide.
-This permits important updates to be pushed to existing Fedora releases
-regardless of the current state of Rawhide.
diff --git a/guidelines/modules/ROOT/pages/WeakDependencies.adoc b/guidelines/modules/ROOT/pages/WeakDependencies.adoc
deleted file mode 100644
index 6c88b5d..0000000
--- a/guidelines/modules/ROOT/pages/WeakDependencies.adoc
+++ /dev/null
@@ -1,110 +0,0 @@
-= Weak Dependencies Policy
-
-== Introduction
-
-Weak dependencies are basically variants of the `+Requires:+` tag and
-are matched against (virtual) `+Provides:+` and package names using
-`+Epoch-Version-Release+` range comparisons, just like regular
-`+Requires:+`. They come in two strengths: "weak" and "hint" and two
-directions "forward" (analogous to `+Requires:+`) and "backwards"
-(which has no analog in the previous dependency system).
-
-[cols=",,",]
-|===============================
-| |Forward |Backward
-|Weak |Recommends: |Supplements:
-|Hint |Suggests: |Enhances:
-|===============================
-
-Weak dependencies allow smaller minimal installations while keeping the default
-installation feature rich. They also allow packages to specify preferences for
-specific providers while maintaining the flexibility of virtual provides, for
-example, preferring ruby vs jruby or community-mysql vs mariadb.
-
-== Weak dependencies
-
-Weak dependencies are by default treated similarly to regular
-`+Requires:+`. Matching packages are added to the dnf transaction. If
-adding the package would lead to an error dnf will by default ignore the
-dependency. This allows users to exclude packages that would be added by weak
-dependencies or remove them later. To skip installing weak dependencies, pass
-`--setopt=install_weak_deps=False` to `dnf`.
-
-As with regular dependencies, weak dependencies MUST be satisfiable within the official Fedora repositories.
-
-Weak dependencies may only be used in a package if the package still functions
-without the dependency present. It is acceptable, however, to create packages
-that have very limited functionality without adding any of its weak
-requirements. Weak dependencies should be used where possible to minimize the
-installation for reasonable use cases, especially for building virtual machines
-or containers that have a single purpose only and do not require the full
-feature set of the package.
-
-Typical use cases for weak dependencies are:
-
-* Documentation
-** Documentation viewers if missing them is handled gracefully
-* Examples
-* Plug-ins or add-ons
-** Support for file formats
-** Support for protocols
-** ...
-
-== Hints
-
-Hints are by default ignored by dnf. They may be used by GUI tools to offer
-add-on packages that are not installed by default but might be useful in
-combination with the installed packages. The requirements of the main use cases
-of a package should not merely be referenced by hints but included by strong or
-weak dependencies.
-
-== Package Preference
-
-dnf (or more precisely libsolv) will use weak dependencies and hints to decide
-which package to use if there is a choice between multiple equally valid
-packages. In these cases packages that are pointed at by dependencies from
-installed or to be installed packages are preferred. Note, that this does not
-alter the normal rules of dependency resolution. For example, weak
-dependencies cannot enforce a older version of a package to be chosen.
-
-If there are multiple (typically virtual) providers for a dependency the
-requiring package may add a Suggests: to provide a hint to the dependency
-resolver as to which option is preferred. `+Enhances:+` should only
-be used for the rare occasion when the main package and other providers agree
-that adding the hint to the required package is for some reason the cleaner
-solution.
-
-=== Real life example
-
-Package A:
-Requires: mysql
-
-Package mariadb:
-Provides: mysql
-
-Package community-mysql:
-Provides: mysql
-
-If you want to prefer mariadb over community-mysql -> add `+Suggests:+`
-`+mariadb+` to Package A.
-
-== Forward vs Backward Dependencies
-
-Forward dependencies are, as Requires, evaluated for packages that are being
-installed. The best of the matching (fulfilling) packages are also installed.
-For reverse dependencies the packages containing the dependency are installed if
-a matching package is getting installed also.
-
-In general forward dependencies should be used. Add the dependency to the
-package getting the other package added to the system.
-
-Reverse dependencies are mainly designed for 3rd party vendors who can attach
-their plug-ins/add-ons/extensions to distribution or other 3rd party packages.
-Within Fedora the control over which packages a package requires should stay
-with the package maintainer. There are, however, cases when it is easier for
-the requiring package not needing to care about all add-ons. In this cases
-reverse dependencies may be used with the agreement of the package maintainer of
-the targeted package.
-
-Note, that EPEL or other third party repositories may have (and are encouraged
-to have) a different policy.
diff --git a/guidelines/modules/ROOT/pages/Web_Assets.adoc b/guidelines/modules/ROOT/pages/Web_Assets.adoc
deleted file mode 100644
index 7f1a7d0..0000000
--- a/guidelines/modules/ROOT/pages/Web_Assets.adoc
+++ /dev/null
@@ -1,164 +0,0 @@
-= Web Assets Packaging Guidelines
-
-== Scope
-
-*Web Assets* are any static content that are shipped intact to web browsers,
-usually by web applications.
-These might be user interface frameworks,
-Flash video players, CSS frameworks, icon libraries,
-or lots of other possibilities.
-
-If your package is primarily or solely shipped to a browser
-and not used locally, and is not JavaScript,
-it probably falls under these guidelines.
-JavaScript packages must follow the
-xref:JavaScript.adoc[JavaScript guidelines]
-in addition to these guidelines.
-
-== Rationale
-
-There are lots of little bits shipped to browsers
-that aren't just JavaScript
-that typically have been bundled along with web applications up to this point.
-xref:JavaScript.adoc#_bundling_of_other_libraries[There are a lot of good reasons why we shouldn't bundle JavaScript this way],
-so it only follows that we should fix it for the rest of that kind of stuff too.
-
-== BuildRequires
-
-To ensure the presence of the necessary RPM macros,
-all packages that provide web assets must have:
-
-[source, rpm-spec]
-----
-BuildRequires:  web-assets-devel
-----
-
-== Requires
-
-To ensure the availability of the necessary directories,
-all packages that provide web assets must have:
-
-[source, rpm-spec]
-----
-Requires:  web-assets-filesystem
-----
-
-Web application packages that ship configuration files for Apache HTTPd
-should ensure that the httpd configuration is installed as well:
-
-[source, rpm-spec]
-----
-Requires:  web-assets-httpd
-----
-
-== RPM Macros
-
-[cols=",,",options="header",]
-|====================================================================================
-|Macro |Normal Definition |Notes
-|_webassetdir |%\{_datadir}/web-assets |The directory where all web assets are stored
-|====================================================================================
-
-== Install Location
-
-All packages that contain static content useful to different web applications
-must install into a subdirectory of `+%{_assetdir}+`.
-For instance,
-the `+jquery-ui+` package should install itself into
-`+%{_webassetdir}/jquery-ui+`.
-
-All packages that contain static content
-that is only useful within the package in which they are shipped
-should continue to ship that content in the application's directory structure.
-However, they must follow the remainder
-of the guidelines outlined in this document.
-
-== Server Location
-
-All HTTP daemons in the distribution
-should make `+%{_webassetdir}+` available in `+/.sysassets+`.
-
-Therefore, if the `+fabulous-web-icons+` package
-ships an icon as `+%{_webassetdir}/fabulous-web-icons/important.png+`,
-you can include it in a web application with the following HTML:
-
-....
-<img src="/.sysassets/fabulous-web-icons/important.png">
-....
-
-Regardless, web applications may want to
-make subdirectories of `+%{_webassetdir}+` available
-under their own directory via aliases or symlinks
-for compatibility purposes or to eliminate needless deviation from upstream.
-
-== Content Guidelines
-
-Web Assets must follow the general guidelines
-for xref:WhatCanBePackaged.adoc[what can be packaged],
-unless stated otherwise in this document.
-
-== CSS
-
-Pure CSS frameworks can be included as-is.
-CSS frameworks that use an alternative language that compiles to CSS,
-such as https://lesscss.org/[LESS],
-must compile to CSS as part of the build process.
-
-Packages containing CSS should make the best effort to regenerate any precompiled/minimized CSS wherever possible,
-as this leads to more maintainable packages.
-Where this would result in a significant hardship,
-the bundled pregenerated CSS may be shipped with a specfile comment explaining the decision.
-This does not eliminate the requirement to validate licenses of bundled content.
-
-== Flash
-
-Flash files (which typically use the `+.swf+` extension)
-must follow the general and licensing guidelines for code,
-not content, and must be built from source
-using a toolchain available in Fedora.
-
-The Flash software needs to be compiled by a free software toolchain,
-such as `+swfc+`.
-xref:WhatCanBePackaged.adoc#prebuilt-binaries-or-libraries[Pre-built `+.swf+` files *must not* be included in Fedora packages.]
-That compilation must be performed as part of the build process for the package.
-
-If the flash software is not compilable using the toolchains inside of Fedora
-then the flash software cannot be shipped.
-In some cases you may be able to patch out use of the flash software
-(for instance, if it's a fallback in case the browser doesn't support HTML5)
-or you may have to give up on packaging the software
-until the flash software toolchain is enhanced to allow building.
-
-== Java applets
-
-Java applets should follow the general and licensing guidelines for code,
-not content.
-Additionally, they should follow the xref:Java.adoc[Java guidelines],
-with the exception that the actual `+.jar+` file for the Java applet
-should be installed into a subdirectory of `+%{_webassetdir}+`.
-
-== Images
-
-Images that are part of a larger Web Asset package
-can be included in that package's subdirectory.
-For instance, a UI library might contain images for its UI components
-in its subdirectory.
-
-Web Asset packages that consist solely of images,
-such as a set of icons, may be shipped as their own package.
-
-== Fonts
-
-All system fonts (available in `+%{_datadir}/fonts+`)
-are automatically made available in `+%{_webassetdir}/fonts/+` via a symlink.
-For more information on packaging system fonts,
-see the xref:FontsPolicy.adoc[font guidelines].
-Please note that only fonts available in the Fedora package collection
-are made available on HTTP servers by default.
-
-Please note that those guidelines prohibit packaging fonts elsewhere.
-There is no compelling reason to support other font formats,
-as most browsers that support web fonts
-support the TTF or OTF formats used by system fonts,
-therefore alternative web font formats like WOFF are prohibited.
-
diff --git a/guidelines/modules/ROOT/pages/WordPress_plugin_packaging_guidelines.adoc b/guidelines/modules/ROOT/pages/WordPress_plugin_packaging_guidelines.adoc
deleted file mode 100644
index f5523ae..0000000
--- a/guidelines/modules/ROOT/pages/WordPress_plugin_packaging_guidelines.adoc
+++ /dev/null
@@ -1,106 +0,0 @@
-= WordPress plugins Packaging Guidelines
-https://wordpress.org/plugins/[WordPress plugins] are packaged for Fedora so that the plugin can be used for both and without requiring both.
-
-== Requirements for packaging
-
-* Use the link:#Specfile_template[specfile template]
-* Set `+plugin_name+` and `+plugin_human_name+` by appending the first two lines appropriately
-** `+plugin_name+` is the short name used in the URL for the plugin's page on wordpress.org
-** `+plugin_human_name+` is the full name of the plugin as displayed on the plugin's page on wordpress.org
-* Fill in the version of the package as it is displayed in the .zip filename
-* Fill in a package description in both places where it says "Your plugin's description goes here."
-
-=== Example
-
-https://wordpress.org/plugins/stats/
-
-....
-%global plugin_name stats
-%global plugin_human_name WordPress.com Stats
-....
-
-== Notes
-
-* The spec must be named `+wordpress-plugin-%{plugin_name}.spec+` as per the Packaging:NamingGuidelines[naming guidelines]
-* Remember to enter a changelog entry
-
-== Specfile template
-
-....
-%global plugin_name
-%global plugin_human_name
-
-Name:       wordpress-plugin-%{plugin_name}
-Version:    
-Release:    1%{?dist}
-Summary:    %{plugin_human_name} plugin for WordPress
-
-Group:      Applications/Publishing
-# According to https://plugins.trac.wordpress.org/ all plugins are licensed
-# under the GPL unless otherwise stated in the plugin source.
-License:    GPL-3.0-or-later
-URL:        https://wordpress.org/plugins/%{plugin_name}/
-Source:     https://downloads.wordpress.org/plugin/%{plugin_name}.%{version}.zip
-BuildRoot:  %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
-Requires:   wordpress
-BuildArch:  noarch
-
-%description
-Your plugin's description goes here.
-
-This package is built for use with WordPress (wordpress), not WordPress MU. Use
-wordpress-mu-plugin-%{plugin_name} for WordPress MU.
-
-
-%package -n wordpress-mu-plugin-%{plugin_name}
-Summary:    %{plugin_human_name} plugin for WordPress MU
-Group:      Applications/Publishing
-# According to https://plugins.trac.wordpress.org/ all plugins are licensed
-# under the GPL unless otherwise stated in the plugin source.
-License:    GPL-3.0-or-later
-Requires:   wordpress-mu
-BuildArch:  noarch
-
-%description -n wordpress-mu-plugin-%{plugin_name}
-Your plugin's description goes here.
-
-This package is built for use with WordPress MU (wordpress-mu), not regular
-WordPress. Use wordpress-plugin-%{plugin_name} for regular Wordpress.
-
-
-%prep
-%setup -q -c
-echo 'To enable "%{plugin_human_name}", go to the administrative section
-of your blog, "Plugins", and enable the plugin there.' > README.fedora
-echo 'To allow users to enable "%{plugin_human_name}" for their blogs,
-be sure to enable this plugin in the administrative control panel
-for your website.' > README.fedora.mu
-
-
-%build
-
-
-%install
-rm -rf %{buildroot}
-mkdir -p %{buildroot}%{_datadir}/wordpress/wp-content/plugins/
-cp -a %{plugin_name} %{buildroot}%{_datadir}/wordpress/wp-content/plugins/
-mkdir -p %{buildroot}%{_datadir}/wordpress-mu/wp-content/plugins/
-cp -a %{plugin_name} %{buildroot}%{_datadir}/wordpress-mu/wp-content/plugins/
-
-
-%clean
-rm -rf %{buildroot}
-
-
-%files
-%doc README.fedora
-%{_datadir}/wordpress/wp-content/plugins/%{plugin_name}
-
-
-%files -n wordpress-mu-plugin-%{plugin_name}
-%doc README.fedora.mu
-%{_datadir}/wordpress-mu/wp-content/plugins/%{plugin_name}
-
-
-%changelog
-....
diff --git a/guidelines/modules/ROOT/pages/_partials/attributes.adoc b/guidelines/modules/ROOT/pages/_partials/attributes.adoc
deleted file mode 100644
index e8e3eeb..0000000
--- a/guidelines/modules/ROOT/pages/_partials/attributes.adoc
+++ /dev/null
@@ -1,12 +0,0 @@
-////
-A collection of useful attributes
-
-To use these in a document, just add the following near the top:
-
-:include::{partialsdir}/attributes.adoc[]
-
-////
-:abi-comparison-tool: https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_in_a_package[ABI comparison tool]
-:packaging-committee: https://pagure.io/packaging-committee[Fedora Packaging Committee]
-:scl-guidelines: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)[Software Collections]
-:updates-policy: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates Policy]
diff --git a/guidelines/modules/ROOT/pages/_partials/versions.adoc b/guidelines/modules/ROOT/pages/_partials/versions.adoc
deleted file mode 100644
index 104773f..0000000
--- a/guidelines/modules/ROOT/pages/_partials/versions.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-////
-Macros for Fedora versions, to replace the wiki's FedoraVersionNumber macro.
-These must be updated manually, but it's not necessary to worry about timing or
-updating them for every single release.
-
-Use these in examples instead of hardcoding Fedora version numbers so that the
-macros don't appear to be out of date just because they reference old Fedora
-versions.
-
-DO NOT use these to indicate that guidelines are specific to certain Fedora
-versions, because then those guidelines will be wrong when these macros are
-updated.  In that you instead simply hardcode the version numbers.
-////
-
-:NEXTVER: 39
-:CURRENTVER: 38
-:PREVVER: 37
diff --git a/guidelines/modules/ROOT/pages/deprecating-packages.adoc b/guidelines/modules/ROOT/pages/deprecating-packages.adoc
deleted file mode 100644
index 3dbb9ea..0000000
--- a/guidelines/modules/ROOT/pages/deprecating-packages.adoc
+++ /dev/null
@@ -1,55 +0,0 @@
-= Deprecating Packages
-
-Sometimes a package is intended to be https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/[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*.
-
-== Prerequisites for deprecation
-
-If nothing in Fedora depends on a package, a maintainer may deprecate it at their leisure. A maintainer (or collection of maintainers) may also deprecate a set of packages together if no package in that set is a dependency of any package outside of that set.
-
-If a package is a dependency of other packages in the distribution (which are not to be deprecated) then deprecation requires a https://fedoraproject.org/wiki/Changes/Policy[FESCo approved Fedora change]. A packager SHOULD communicate package deprecation to other maintainers, preferably via the https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel] or https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/[devel-announce] mailing lists.
-
-== Marking a package deprecated
-
-In order to mark a package deprecated, a special virtual provides is added:
-
-....
-Provides: deprecated()
-....
-
-If the package has subpackages and the packager intends to deprecate the package as a whole, packager MUST mark all subpackages as being deprecated.
-
-....
-Name:      mainpackage
-...
-Provides:  deprecated()
-
-...
-
-%package subpackage
-...
-Provides:  deprecated()
-....
-
-Alternatively, a packager MAY decide to only deprecate some subpackages.
-
-A packager SHOULD add a comment in the spec explaining why a package is being deprecated. For example:
-
-....
-# net-tools (ifconfig etc.) have been obsoleted for ~20 years upstream.
-# We want to get rid of it from Fedora in favor of the iproute package,
-# however many sysadmins still expect ifconfig to be there, so we keep it
-# around as a deprecated package.
-Provides:  deprecated()
-....
-
-If a date for the final removal of the package from the distribution is known, it MAY be included as follows:
-
-....
-Provides:  deprecated() = YYYYMMDD
-....
-
-The special `+deprecated()+` provide MUST NOT be added in any released branch of Fedora. It is acceptable to deprecate packages in rawhide (the master branch), the branch for an upcoming Fedora release (if one exists) up until the time of the https://fedoraproject.org/wiki/Schedule[Final Freeze], and to EPEL branches (at any time). Also note that because packages may exist in a deprecated state for some time, those packages can eventually enter release branches. The restriction is on the initial addition of the `+deprecated()+` tag.
-
-== Consequences of a package being deprecated
-
-Technically, nothing changes; a deprecated package works and behaves as before. However, other packages in Fedora MUST NOT add a dependency on a deprecated package (that includes Requires, BuildRequires, Recommends, Suggests, etc.). This applies both for updates of existing packages and new packages added to Fedora. Those submitting new packages, along with package reviewers, MUST check to see if any dependencies of the package they are submitting or reviewing have been deprecated. (It is, however, acceptable for a deprecated package to be renamed.)
diff --git a/guidelines/modules/ROOT/pages/index.adoc b/guidelines/modules/ROOT/pages/index.adoc
deleted file mode 100644
index 8336c61..0000000
--- a/guidelines/modules/ROOT/pages/index.adoc
+++ /dev/null
@@ -1,3303 +0,0 @@
-= Fedora Packaging Guidelines
-:abi-comparison-tool: https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_in_a_package[ABI comparison tool]
-:packaging-committee: https://pagure.io/packaging-committee[Fedora Packaging Committee]
-:scl-guidelines: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)[Software Collections]
-:updates-policy: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates Policy]
-
-The Packaging Guidelines are a collection of common issues
-and the severity that should be placed on them.
-While these guidelines should not be ignored,
-they should also not be blindly followed.
-If you think that your package should be exempt from part of the Guidelines,
-please bring the issue to the {packaging-committee}.
-
-These documents cover the fine details of acceptable Fedora packaging
-and while they may include various examples
-they will not be particularly useful as a tutorial.
-They also do not cover the details
-and policies relating to gaining access
-to the Fedora repositories as a packager,
-or the mechanics of actually creating and releasing packages
-as part of the distribution.
-For documents which cover those issues,
-please see the following:
-
-* https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/[Join the Package Maintainers]
-* https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_Existing_Contributors/[New Package Process for Existing Contributors]
-* https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial/[Packaging Tutorial]
-
-It is the package reviewer's responsibility to point out specific problems with a package
-and a packager's responsibility to deal with those issues.
-The reviewer and packager work together to determine the severity of the issues
-(whether they block a package
-or can be worked on after the package is in the repository.)
-Please remember that any package that you submit
-must also conform to the xref:ReviewGuidelines.adoc[Review Guidelines].
-
-The original author of these documents is
-https://fedoraproject.org/wiki/TomCallaway[Tom 'spot' Callaway],
-though they were originally based on many other documents.
-They have been significantly modified over the years
-by many members of the Packaging Committee.
-
-The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY
-in these guidelines are to be interpreted as described in
-https://www.rfc-editor.org/rfc/rfc2119[RFC 2119].
-
-Report issues with these guidelines, including typos,
-https://pagure.io/packaging-committee[here].
-
-== Applicability
-
-In general,
-these guidelines apply to the currently released,
-non-end-of-life versions of Fedora,
-as well as the development version of Fedora (Rawhide).
-If a particular portion of these guidelines is relevant
-only to a subset of those releases,
-this will be specifically noted.
-However, please note that Rawhide can change rapidly,
-and there will be times when changes are visible there
-which are not yet reflected here.
-
-The guidelines also to some degree cover packages for EPEL,
-but only when combined with the
-https://docs.fedoraproject.org/en-US/epel/epel-packaging/[EPEL packaging guidelines].
-Fedora packaging changes far more rapidly than EPEL packaging,
-so over time these guidelines will drift further away
-from any particular EPEL release
-and for the older supported EPEL release
-the differences can be quite significant.
-Portions of these guidelines which do not apply to EPEL
-will not generally be indicated.
-
-== General Exception Policy
-
-As these guidelines can never cover all possible contingencies,
-there will always be packages which need exceptions.
-It is the packager's responsibility to follow these guidelines
-as closely as is feasible and to clearly document,
-as comments in the package specfile,
-instances where they cannot be followed.
-
-If, in a guideline, the language "should" or "is suggested" is used
-and it is not feasible for the package to conform to that guideline,
-the packager may deviate from the it.
-The nature of the deviation and the reasoning behind it
-MUST be documented in the specfile.
-
-Where the language "must", "is required to" or "needs to" is used,
-the packager may deviate from the guideline
-only with approval from the packaging committee.
-Please follow the procedure at the
-https://fedoraproject.org/wiki/Packaging_Committee#Bringing_Issues_to_the_Committee[Packaging Committee]
-page for making these requests.
-
-== Allowed Packages
-
-Please review
-xref:what-can-be-packaged.adoc[What Can Be Packaged]
-to ensure that what is to be packaged is allowed in Fedora.
-
-== Naming
-
-You should go through the
-xref:Naming.adoc[Naming Guidelines]
-to ensure that your package is named appropriately.
-
-== Version and Release
-
-Documentation covering the proper way to use the Version and Release fields
-can be found xref:Versioning.adoc[here].
-
-== Licensing
-
-You should review the information regarding 
-xref:legal::license-approval.adoc[licenses determined to be allowed in Fedora] 
-and the xref:LicensingGuidelines.adoc[Licensing Guidelines]
-to ensure that your package is licensed appropriately
-and that the license is properly indicated.
-
-=== Fedora Trademarks
-
-Packagers *MUST NOT* add any Fedora trademark assets
-including the Fedora logo,
-Fedora logo icons,
-or graphics that include the Fedora logo.
-Those assets *MUST* be added to the fedora-logos package.
-Your packages(s) install the logos by depending on the fedora-logos package.
-If the upstream contains Fedora trademark assets
-that you believe are used inappropriately,
-email legal@fedoraproject.org
-
-This is because the Fedora logo is a trademark,
-which are handled under a different legal framework than code.
-It must only be distributed under terms that protect the trademark.
-Keeping Fedora trademarks separate in their own package
-instead of scattered across various other packages
-is also an essential practice for enabling remixes
-that necessarily must
-https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Secondary_Mark[not use the Fedora trademark],
-and instead roll their own *-logos package
-or use the generic-logos package.
-
-== Libraries and Applications
-
-Many language- or domain-specific guidelines refer to "libraries",
-"modules", "plug-ins" or other terms specific to the language or
-domain. This is specifically important to package
-naming. Some applications may include libraries, and some libraries
-may include applications, so the distinction is not always clear.
-
-=== Library or Application?
-
-* If the primary purpose of a package
-is to provide executables to be run by users,
-it SHOULD be packaged as an application.
-If it also includes libraries which may be imported
-or linked to by other code,
-see <<Mixed Use Packages>> below.
-* If the primary purpose of a package
-is to provide libraries intended to be imported or loaded into other code,
-it is considered a library and MUST be packaged as such.
-If it contains utility programs that can be run by users as well,
-see <<Mixed Use Packages>> below.
-
-It is left to the packager to determine the primary purpose of a package.
-Often times upstream will already have done this
-with their choice of naming
-and that choice SHOULD be followed by the Fedora packager.
-
-=== Mixed Use Packages
-
-Many packages, regardless of their primary purpose,
-include both applications and libraries.
-In this case one or both SHOULD be packaged in subpackages
-in order to allow other applications to depend on only the library
-and not the associated application(s).
-Installing an application that depends on a library or service
-should not automatically pull in other applications
-associated with that library or service.
-
-== Package Independence
-
-Packages SHOULD be installable independently whenever this is technically feasible,
-but they MUST specify dependencies of correct type on other packages if necessary,
-see <<Dependency Types>> below.
-
-Desktop applications MUST NOT depend on other desktop applications
-unless strictly required.
-In particular, packages that contain a visible `.desktop` file
-(a `.desktop` file that does not contain the line `+NoDisplay=true+`)
-SHOULD NOT have a `Requires`,
-`Recommends`,
-or `Supplements`
-on any other package containing a visible desktop file,
-directly or indirectly.
-
-For example, it would be reasonable for a video game level editor
-to require the associated video game in order to function,
-or for an application's plugin to require the associated application.
-But it would not be reasonable for an application
-that happens to use a database library
-to depend on a database management suite associated with that library,
-or for an application that happens to use a particular programming language
-to depend on management tools associated with that programming language.
-
-If a source package provides multiple graphical applications,
-those applications SHOULD be packaged in separate subpackages when feasible.
-
-== Spec Files
-
-The spec file ("spec") is a fundamental element in the packaging workflow.
-Any change that is made to the package will include a change to the spec.
-Because packages in Fedora are maintained by a community of packagers
-as well as automated tooling,
-it is important for the specs to follow certain conventions.
-The bulk of these packaging guidelines involves what goes into a spec,
-but here are a few general items.
-
-=== Spec File Naming
-
-The spec file MUST be named `+%{name}.spec+`.
-That is, if your package is named `+example+`,
-the spec file must be named `+example.spec+`.
-
-=== Spec Legibility
-
-All spec files MUST be legible and maintained in such a way
-that the community of packagers is able to understand and work with them.
-
-To help facilitate legibility,
-only macros and conditionals for Fedora and EPEL
-are allowed to be used in Fedora Packages.
-Use of macros and conditionals for other distributions,
-including Fedora derivatives,
-is not permitted in spec files of packages in the main Fedora repositories
-unless those macros and conditionals are also present in Fedora.
-
-=== Spec File Encoding
-
-Unless you need to use characters outside the
-https://commons.wikimedia.org/wiki/File:Ascii_full.png[ASCII repertoire],
-you will not need to be concerned about the encoding of the spec file.
-If you do need non-ASCII characters,
-save your spec files as UTF-8.
-If you're in doubt as to what characters are ASCII,
-please refer to
-https://commons.wikimedia.org/wiki/File:Ascii_full.png[this chart].
-
-==== Non-ASCII Filenames
-
-Similarly, filenames that contain non-ASCII characters
-must be encoded as UTF-8.
-Since there's no way to note which encoding the filename is in,
-using the same encoding for all filenames is the best way
-to ensure users can read the filenames properly.
-If upstream ships filenames that are not encoded in UTF-8
-you can use a utility like convmv
-(from the convmv package)
-to convert the filename in your %install section.
-
-=== Spec Maintenance and Canonicity
-
-Fedora's git repository is the canonical location for Fedora spec files.
-Maintainers MUST expect that other maintainers
-and automated tooling will make changes to their packages,
-potentially without communicating prior to doing so
-(though communication is always encouraged).
-If some maintainers are also attempting
-to keep copies of a spec in an outside repository,
-they MUST be prepared to merge changes made to the spec
-in Fedora's repository,
-and MUST NOT overwrite those changes
-with a copy from an external repository
-or using `+fedpkg import+`.
-
-== Source File Verification
-
-Where the upstream project publishes OpenPGP signatures of their releases,
-Fedora packages *SHOULD* verify that signature as part of the RPM build process.
-
-Although a checksum in the sources file certifies
-that a file retreived from the lookaside cache
-is the one that the packager uploaded,
-it is silent on whether the file is what the upstream project released.
-A signature by the upstream developers certifies
-that the source is identical to what they released.
-Verifying the signature as part of the build ensures
-that packagers don't forget to verify it.
-
-=== Obtaining the Correct Keys
-
-The verification method requires one or more OpenPGP keyring files
-with public keys from the upstream project.
-The keyrings shall together contain all the keys that are trusted
-to certify the authenticity of the sources,
-and *MUST NOT* contain any other keys.
-
-Ideally the upstream project publishes such a keyring as a downloadable file.
-You shall download that file
-and do everything you reasonably can to verify that it is authentic.
-Then you shall add it unmodified to the package SCM,
-and provide its URL in the spec file
-so that others can verify it.
-The URL *MUST* use HTTPS
-or a similarly authenticated protocol if at all possible.
-
-Even if you are unable to verify the key at the first addition,
-it still enhances security in a trust-on-first-use way.
-It will ensure that future attacks will be detected
-if the key is the right one,
-or that a current attack will be detected later
-if future releases are signed by the correct key.
-
-=== Verifying Signatures
-
-When source file verification is done,
-it *MUST* be done first in the `%prep` section of the spec file,
-before any potentially compromised code is executed.
-The verification *MUST* be done with the macro `+%{gpgverify}+`,
-which expands into a command
-whose parameters shall be the pathnames of the keyring,
-the signature and the signed file.
-`BuildRequires: gpgverify` is necessary for the verification to work.
-
-Any detached signature file
-(e.g. foo.tar.gz.asc or foo.tar.gz.sig)
-must be uploaded to the package lookaside cache alongside the source code,
-while the keyring must be committed directly to the package SCM.
-
-The following format must be used:
-
-[source, rpm-spec]
-----
-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
-…
-BuildRequires: gpgverify
-…
-%prep
-%{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}' --data='%{SOURCE0}'
-----
-
-The first source is the actual tarball,
-the second one is the signature from upstream,
-and the third one is the keyring.
-
-=== Exceptions
-If the upstream tarball of a package needs to be modified,
-for example because it contains forbidden items,
-then the tarball cannot be verified as part of the build process.
-In this case
-the upstream OpenPGP keyring must still be included in the package SCM
-and the instructions/script used to build the stripped-down tarball
-needs to verify the upstream source.
-
-If the upstream project does not publish a keyring file
-(for example if they publish only a fingerprint on their website
-and refer to a keyserver network for downloading the key),
-then you may need to create a keyring after you have verified the key.
-In this case there is no upstream URL to the keyring,
-so instead you should document how you created the keyring
-in a comment in the spec file.
-A minimal keyring with the key with the fingerprint
-`7D33D762FD6C35130481347FDB4B54CBA4826A18`
-can be created with the following command:
-
-....
-gpg2 --export --export-options export-minimal 7D33D762FD6C35130481347FDB4B54CBA4826A18 > gpgkey-7D33D762FD6C35130481347FDB4B54CBA4826A18.gpg
-....
-
-If upstream signed a tarball differently,
-for example by signing only the uncompressed tarball
-but distributing a compressed version,
-then the verification step must be adjusted accordingly,
-for example:
-
-[source, rpm-spec]
-----
-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
-…
-BuildRequires: gpgverify xz
-…
-%prep
-xzcat '%{SOURCE0}' | %{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}' --data=-
-----
-
-If the data and the signature are combined in a single file,
-then the signed data must be written to an output file:
-
-[source, rpm-spec]
-----
-%{gpgverify} --keyring='%{SOURCE1}' --data='%{SOURCE0}' --output=<pathname>
-----
-
-Packages that are vital during bootstrapping of Fedora
-may use a <<bootstrapping,bootstrap flag>>
-to skip the verification before GPGverify and GnuPG have been built.
-
-=== Help
-
-If you need help getting your package compliant to this guideline,
-or if you do not know what to do if a build fails on a signature verification,
-then you should seek help on the Fedora devel mailing list
-before circumventing the check,
-to make sure that you do not build compromised software.
-
-== Architecture Support
-
-All Fedora packages must successfully compile and build
-into binary rpms on at least one supported primary architecture,
-except where the package is useful only on a secondary architecture
-(such as an architecture-specific boot utility, microcode loader,
-or hardware configuration tool).
-Fedora packagers should make every effort to support all
-https://fedoraproject.org/wiki/Architectures#Primary_Architectures[primary architectures].
-
-Content, code which does not need to compile or build,
-and architecture independent code (noarch) are notable exceptions.
-
-=== Architecture Build Failures
-
-If a Fedora package does not successfully compile, build or work on an architecture,
-then those architectures should be listed in the spec in `+ExcludeArch+`.
-Each architecture listed in `+ExcludeArch+`
-needs to have a bug filed in bugzilla,
-describing the reason that the package does not
-compile/build/work on that architecture.
-The bug number should then be placed in a comment,
-next to the corresponding `+ExcludeArch+` line.
-New packages will not have bugzilla entries during the review process,
-so they should put this description in the comment
-until the package is approved,
-then file the bugzilla entry,
-and replace the long explanation with the bug number.
-The bug should be marked as blocking one (or more)
-of the following bugs to simplify tracking such issues:
-
-* https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-x86[F-ExcludeArch-x86]
-* https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-x64[F-ExcludeArch-x64]
-* https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM[F-ExcludeArch-ARM]
-* https://bugzilla.redhat.com/show_bug.cgi?id=PPCTracker[PPCTracker]
-* https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-s390x[F-ExcludeArch-s390x]
-
-=== Noarch with Unported Dependencies
-
-Sometimes, you are working on a noarch package
-that can only run in locations that a different,
-arched package builds on.
-This is common for packages written in a scripting language
-which depend on the language's interpreter package, for instance.
-If the arched package that your package deps on isn't available
-on all architectures Fedora (or EPEL) targets
-you run into a situation where you may need to exclude your package
-from certain architectures' package repositories
-or prevent it from building on certain architectures in the buildsystem.
-
-==== Arch-Specific Runtime and Build-Time Dependencies
-
-You can limit both the architectures used to build a noarch package,
-and the repositories to which the built noarch package will be added,
-by using either the `+ExcludeArch:+` or `+ExclusiveArch:+` tags:
-
-[source, rpm-spec]
-----
-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,
-`+%{nodejs_arches}+`.
-If it does exist, then you can use something like
-`+ExclusiveArch: %{nodejs_arches} noarch+`
-in your spec file.
-Take a look at the guidelines for the language
-to see if such a macro exists.
-
-=== No Arch-Specific Sources or Patches ===
-
-Packages MUST NOT have `+Source:+` or `+Patch:+` tags
-which are conditionalized on architecture.
-For example, this is forbidden:
-
-[source, rpm-spec]
-----
-%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
-depending on the architecture which was used to build it.
-
-Note that this unfortunately prevents `+%autosetup+`
-from being used to apply patches
-when some of those patches apply only to certain architectures.
-The best solution is to write patches
-which simply work on all architectures.
-If that is not possible, then simply use `+%autosetup -N+`
-and to use the `+%patch+` macro to apply each patch
-using `+%ifarch+` or `+%ifnarch+` as appropriate.
-For example:
-
-[source, rpm-spec]
-----
-%prep
-%autosetup -N
-%ifarch s390x
-%patch 0 -p1
-%endif
-----
-
-== Filesystem Layout
-
-Fedora follows the
-https://refspecs.linuxfoundation.org/fhs.shtml[Filesystem Hierarchy Standard]
-with regards to filesystem layout,
-with exceptions noted below.
-The FHS defines where files should be placed on the system.
-
-=== Exceptions
-
-* Fedora allows cross-compilers to place files in `+/usr/target+`.
-
-* The `/nix` top-level directory may be used exclusively for Nix runtime and package store.
-  It may only be created and owned by the `nix-filesystem` package.
-
-* Fedora does not allow new directories
-  directly under `+/+` or `+/usr+` without FPC approval.
-
-=== Libexecdir
-
-The https://www.pathname.com/fhs/[Filesystem Hierarchy Standard]
-does not include any provision for libexecdir,
-but Fedora packages MAY store appropriate files there.
-Libexecdir (aka, `+/usr/libexec+` on Fedora systems)
-should only be used as the directory for executable programs
-that are designed primarily to be run by other programs
-rather than by users.
-
-Fedora's rpm includes a macro for libexecdir,
-`+%{_libexecdir}+`.
-Packagers are highly encouraged to store libexecdir files
-in a package-specific subdirectory of `+%{_libexecdir}+`,
-such as `+%{_libexecdir}/%{name}+`.
-
-If upstream's build scripts support the use of `+%{_libexecdir}+`
-then that is the most appropriate place to configure it
-(e.g., passing `+--libexecdir=%{_libexecdir}/%{name}+` to autotools configure).
-If upstream's build scripts do not support that,
-`+%{_libdir}/%{name}+` is a valid second choice.
-If you have to patch support for using one of these directories in,
-then you should patch in LIBEXECDIR,
-preferably configurable at build time
-(so distributions that do not have `+/usr/libexec+`
-can set LIBEXECDIR to another directory
-more appropriate for their distro).
-
-=== Multilib Exempt Locations
-
-If a package is exempt from multilib,
-it may use `+%{_prefix}/lib+` instead of `+%{_libdir}+`.
-Packages that contain architecture specific files
-that would ordinarily be installed into `+%{_libexecdir}+`
-are always considered ineligible for multilib.
-However, you should be sure that the (sub)package that they are in
-does not have other content that would be considered eligible for multilib.
-If this is not the case for the files you wish to do this in for your package
-or you are just unsure, ask FESCo for an explicit multilib exemption.
-
-=== `+/run+`
-
-System services should store small volatile run-time data in `+/run+`.
-This is a tmpfs backed directory that is mounted in very early boot,
-before any services are started
-(and before `+/var+` is available).
-`+/var/run+` is a legacy symlink to `+/run+`.
-
-=== No Files or Directories Under `+/srv+`, `+/usr/local+`, or `+/home/$USER+`
-
-The https://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM[FHS says]:
-
-....
-"...no program should rely on a specific subdirectory structure of /srv existing
-or data necessarily being stored in /srv. However /srv should always exist on FHS
-compliant systems and should be used as the default location for such data.
-
-Distributions must take care not to remove locally placed files in these
-directories without administrator permission."
-....
-
-The FHS is explicitly handing control of the directory structure
-under `+/srv+` to the system administrator rather than the distribution.
-Therefore, no Fedora packages can have any files or directories under `+/srv+`,
-come preconfigured to use specific files or directories under `+/srv+`,
-to remove files there, or to modify the files there in any way.
-
-In addition, no Fedora package can
-contain files or directories or modify files under:
-
-* `+/usr/local+`
-as these directories are not permitted to be used
-by Distributions in the FHS
-* `+/home/$USER+`
-as users can arbitrarily modify the files in their home directories
-and rpm packages that modify those files run the risk of destroying user data.
-Additionally, sites may be nfs mounting `+/home+`
-on many different types of systems
-or even network automounting them on demand.
-Modifying files in home directories that are thus configured
-will have negative effects in both of these situations.
-
-It is important to note that the software in a Fedora package,
-once installed and configured by a user,
-can use `+/srv+` as a location for data.
-The package simply must not do this out of the box
-
-=== Limited Usage of `+/opt+`, `+/etc/opt+`, and `+/var/opt+`
-
-`+/opt+` and its related directories (`+/etc/opt+` and `+/var/opt+`)
-is reserved for the use of vendors in the FHS.
-We have reserved the `+fedora+` name with
-https://www.lanana.org/lsbreg/providers/providers.txt[LANANA]
-for our use.
-If a package installs files into `+/opt+`
-it may only use directories in the `+/opt/fedora+` hierarchy.
-Fedora attempts to organize this directory by allocating a subdirectory
-of our `+/opt/fedora+` directory for specific subsystems.
-If you think you need to use `+/opt/fedora+`
-please file an FPC ticket to decide whether it's a valid use of `+/opt+`
-and what subdirectory should be allocated for your use.
-
-Currently, we have allocated
-`+/opt/fedora/scls+`, `+/etc/opt/fedora/scls+`, and `+/var/opt/fedora/scls+`
-for use by {scl-guidelines}.
-
-Because the Google-supplied Chrome packaging has chosen
-a specific file location for extension-specific files which,
-if used, would conflicts with the above guidelines,
-the Packaging Committee has approved the following exception:
-A package MAY install files into the
-`+/etc/opt/chrome/native-messaging-hosts+` directory,
-and may create that directory hierarchy,
-as long as package as a whole also supports Chromium.
-(The Chromium support MAY be in a different subpackage.)
-If Chrome in the future allows a more standard directory
-to be used for this purpose, this exception will be removed.
-
-=== Merged file system layout
-
-Fedora has merged several directories that historically used to be
-separate.
-
-[cols=",,"]
-|===
-|Path|Merged with|RPM Macro
-
-|`+/bin+`
-|`+/usr/bin+`
-|`+{_bindir}+`
-
-|`+/sbin+`
-|`+/usr/bin+`
-|`+%{_bindir}+`
-
-|`+/usr/sbin+`
-|`+/usr/bin+`
-|`+%{_bindir}+`
-
-|`+/lib64+` or `+/lib+`
-|`+/usr/lib64+` or `+/usr/lib+`
-|`+%{_libdir}+`
-
-|`+/lib+`
-|`+/usr/lib+`
-|`+%{_prefix}/lib+`
-|===
-
-For example, end users will find that
-`+/bin/sh+` is the same file as `+/usr/bin/sh+`,
-and `+/usr/sbin/sendmail+` is the the same as `+/usr/bin/sendmail+`.
-
-However,
-rpm file dependencies don't work according to what's on the filesystem,
-they work according to the path specified in the rpm `+%files+` section.
-So an rpm which specified:
-
-[source, rpm-spec]
-----
-%files
-/bin/sh
-----
-
-would be able to satisfy a file dependency for `+/bin/sh+`
-but not for `+/usr/bin/sh+`.
-Packages **must** use the real filesystem paths in the `+%files+` section.
-If other packages have dependencies on a different path
-that resolves to the same file,
-and it is not convenient to update them to the new path,
-packages **may** use a virtual `+Provides+` to list the alternate path.
-
-For instance:
-
-[source, rpm-spec]
-----
-Provides: /sbin/ifconfig
-[...]
-%files
-%{_bindir}/ifconfig
-----
-
-== Use `+rpmlint+`
-
-Run rpmlint on binary and source rpms to examine them for common errors,
-and fix them (unless rpmlint is wrong, which can happen, too).
-If you find rpmlint's output cryptic,
-the `+-e+` switch to it can be used
-to get more verbose descriptions of most errors and warnings.
-Note that rpmlint will perform additional checks
-if given the name of an installed package.
-For example,
-`+dnf install foo-1.0-1.f20.x86_64.rpm; rpmlint -i foo+`
-will perform a set of tests on the foo package that
-`+rpmlint foo-1.0-1.f20.x86_64.rpm+` cannot.
-A community-maintained page on rpmlint issues can be found
-https://fedoraproject.org/wiki/Common_Rpmlint_issues[here].
-
-== Tags and Sections
-
-* The `+Copyright:+`, `+Packager:+`, `+Vendor:+` and `+PreReq:+` tags
-MUST NOT be used.
-* The `+BuildRoot:+` tag, `+Group:+` tag, and `+%clean+` section
-SHOULD NOT be used.
-* The contents of the buildroot SHOULD NOT be removed
-in the first line of `+%install+`.
-* The `+Summary:+` tag value SHOULD NOT end in a period.
-* The `+Source:+` tags document where to find
-the upstream sources for the package.
-In most cases this SHOULD be a complete URL to the upstream tarball.
-For special cases, please see the
-xref:SourceURL.adoc[SourceURL Guidelines].
-* URLs in the `+URL:+`, `+Source:+` and `+Patch:+` tags
-SHOULD require authentication of the server whenever possible.
-This typically means writing `+https:+` instead of `+http:+` or `+ftp:+`.
-
-== Package Dependencies
-
-All package dependencies
-(build-time or runtime, regular, weak or otherwise)
-MUST ALWAYS be satisfiable within the official Fedora repositories.
-
-RPM can automatically determine dependencies for most compiled libraries
-and for some scripting languages such as Perl.
-Automatically determined dependencies MUST NOT be duplicated
-by manual dependencies.
-
-Build dependencies, however, MUST be explicitly listed,
-unless you are using an automatic build dependency generator
-(e.g. xref:Rust.adoc#_buildrequires[Rust] or
-xref:Python.adoc#_build_time_dependency_generator[Python]).
-Refer to the <<buildrequires>>.
-
-Versioned dependencies (build-time or runtime) SHOULD ONLY be used
-when actually necessary to guarantee
-that the proper version of a package is present.
-If a versioned dependency would be satisfied
-by a version present in three previous Fedora releases
-then a versioned dependency is not needed
-and a regular unversioned dependency SHOULD be used instead.
-
-A versioned dependency on a package with a defined Epoch
-MUST be included in that dependency.
-Otherwise the dependency will not function as expected.
-
-=== Dependency Types
-
-`Requires` MUST be used if the dependency is required
-for the software to function correctly.
-
-If the package functions correctly but in diminished capacity,
-then `Recommends` or `Suggests` SHOULD be used.
-If the functionality should be available by default for users,
-`Recommends` SHOULD be used,
-and `Suggests` otherwise.
-Alternatively, the reverse dependencies
-`Supplements` or `Enhances`
-may be used in the other package.
-See xref:WeakDependencies.adoc[Packaging:WeakDependencies]
-for guidelines on using those dependency types.
-
-=== Architecture-specific Dependencies
-
-A dependency is made arch-specific by appending the macro `+%{?_isa}+`
-to the package name.
-For example:
-
-[source, rpm-spec]
-----
-Requires: foo
-----
-
-becomes:
-
-[source, rpm-spec]
-----
-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
-to get strong hints what packages should be marked as foo's requirements.
-For example:
-
-....
-$ gtk-config --cflags
--I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
-$ gtk-config --libs
--L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
-....
-
-This means that gtk+-devel should contain
-
-`+Requires: glib-devel%{?_isa} libXi-devel%{?_isa} libXext-devel%{?_isa} libX11-devel%{?_isa}+`
-
-=== Rich/Boolean Dependencies
-
-Packages MAY make full use of the
-https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html[rich (or Boolean) dependency feature]
-supported in RPM.
-
-=== File and Directory Dependencies
-
-RPM gives you the ability to depend on arbitrary files or directories
-instead of packages.
-Packages MAY include such dependencies for paths inside one of the following directories:
-
-* `+/usr/bin+`
-* `+/etc+`
-
-They also MAY depend on paths listed in an explicit `Provides:`.
-They MUST NOT include dependencies on other paths,
-as that would require downloading of additional repository metadata to be enabled.
-
-Please also note that it is not uncommon
-for multiple packages to provide the same directory.
-Directory dependencies SHOULD ONLY be used
-to express the dependency on that directory existing,
-not on any other functionality of any other package
-that might provide that directory.
-
-When declaring file and directory dependencies,
-xref:RPMMacros.adoc#macros_installation[installation path macros] like `+%{_bindir}+`
-MUST NOT be used.
-`+%{_bindir}+` of the package that provides `+sometool+`
-may be different from `+%{_bindir}+` of a package that requires `+sometool+`.
-In such case, `+BuildRequires: %{_bindir}/sometool+` does not work as expected.
-
-=== Explicit Requires
-
-Explicit Requires are Requires added manually by the packager in the spec file.
-Packages must not contain unnecessary explicit Requires on libraries.
-We generally rely on rpmbuild to automatically add dependencies
-on library SONAMEs.
-Modern package management tools are capable of resolving such dependencies
-to determine the required packages in many cases.
-However, present versions of rpmbuild only add deps on library SONAMES,
-not the library's full version.
-This can be a problem if a library has added features over the course of time
-without backwards incompatibilities that would cause SONAMES to be changed.
-This can lead to a case where the user has an old version
-of a library installed,
-the new version of the library with new ABI is built in Fedora
-and an application using that ABI is built.
-If the user just attempts to install or update that one application
-without also updating the library,
-the application will install fine
-(because the SONAME dependency is satisfied)
-but will fail when run because the library installed
-on the system is missing features it needs.
-
-Although you do need to add explicit library dependencies
-to keep this from occurring,
-there are drawbacks to manually specifying this in all your packages.
-History has shown that such dependencies add confusion
-when library/files are moved from one package to another,
-when packages get renamed,
-when one out of multiple alternative packages would suffice,
-and when versioned explicit dependencies become out-of-date and inaccurate.
-Additionally, in some cases,
-old explicit dependencies on package names
-require unnecessary updates/rebuilds.
-For example,
-Fedora packages are only required to retain historical provides
-for two full release cycles.
-
-Because of this and because we hope to have this fixed in rpmbuild,
-this is something to be aware of
-but it's not required that you explicitly specify the libraries you require
-with their version information.
-
-When explicit library Requires are necessary,
-explicit library dependencies should typically be arch-specific
-(unless the packages involved are noarch)
-and there should be a spec file comment justifying it:
-
-[source, rpm-spec]
-----
-# 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.
-For instance in the example above,
-when no current Fedora release shipped with libfubar < 1.2.3-7,
-it is no longer necessary to list the explicit, versioned requirement.
-
-=== Filtering Auto-Generated Requires
-
-RPM attempts to auto-generate Requires (and Provides) at build time,
-but in some situations,
-the auto-generated Requires/Provides are not correct or not wanted.
-For more details on how to filter out auto-generated Requires or Provides,
-please see:
-xref:AutoProvidesAndRequiresFiltering.adoc[Packaging:AutoProvidesAndRequiresFiltering].
-
-[#buildrequires]
-== Build-Time Dependencies (BuildRequires)
-
-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.
-
-=== BuildRequires and `+%{_isa}+`
-
-You MUST NOT use arched BuildRequires.
-The arch ends up in the built SRPM
-but SRPMs need to be architecture independent.
-For instance, if you did this:
-
-[source, rpm-spec]
-----
-# 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:
-
-....
-foo(x86-32) >= 3.3
-# or
-foo(x86-64) >= 3.3
-....
-
-This would prevent yum-builddep
-or similar tools that use the SRPM's requirements
-from operating correctly.
-
-=== BuildRequires Based on `+pkg-config+`
-
-Fedora packages which use `+pkg-config+`
-to build against a library (e.g. 'foo') on which they depend,
-*SHOULD* express their build dependency correctly as `+pkgconfig(foo)+`.
-For more information, see
-xref:PkgConfigBuildRequires.adoc[Packaging:PkgConfigBuildRequires].
-
-== Conditional Build-Time Dependencies
-
-If the spec file contains conditional dependencies
-selected based on presence of optional
-`+--with(out) foo+` arguments to `+rpmbuild+`,
-build the source RPM to be submitted with the default options,
-i.e., so that none of these arguments are present
-in the `+rpmbuild+` command line.
-The reason is that those requirements get "serialized"
-into the resulting source RPM,
-i.e., the conditionals no longer apply.
-
-== Summary and Description
-
-The summary should be a short and concise description of the package.
-The description should expand upon this.
-
-=== Dos and Don'ts
-
-* Do not end the summary with a period.
-* The summary should be 80 characters/columns or less.
-  If you are using something other than ASCII
-  look at a utf length function or something similar
-  to calculate the column count.
-* Make sure that there are no lines in the description longer than 80 characters/columns.
-  If you are using something other than ASCII
-  look at a utf length function or something similar
-  to calculate the column count.
-* 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 consistency,
-  we use the American English spelling and grammar rules
-  in the summary and description.
-  Packages can contain additional translated summary/description
-  for supported Non-English languages,
-  if available.
-
-=== Trademarks in Summary or Description
-
-Packagers should be careful how they use trademarks
-in Summary or Description.
-There are a few rules to follow:
-
-* Never use `\(TM)`  or `\(R)` (or the Unicode equivalents, ™/®).
-It is incredibly complicated to use these properly,
-so it is actually safer for us to not use them at all.
-* Use trademarks in a way that is not ambiguous.
-Avoid phrasing like "similar to" or "like". Some examples:
-
-* *BAD:* It is similar to Adobe Photoshop.
-* *GOOD:* It supports Adobe Photoshop PSD files, ...
-
-* *BAD:* A Linux version of Microsoft Office
-* *GOOD:* A word-processor with support for Microsoft Office DOC files
-
-If you're not sure, ask yourself,
-is there any chance someone may get confused
-and think that this package is the trademarked item?
-When in doubt, try to leave the trademark out.
-
-== Documentation
-
-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 xref:LicensingGuidelines.adoc[Licensing Guidelines]
-for how to handle them.
-
-=== Separate Documentation Packages
-
-If building documentation requires many additional dependencies
-then you MAY elect to not build it in the main package
-and instead create a separate *-doc source package
-which builds only the documentation.
-This separately packaged documentation MUST correspond
-to the version of the packaged software.
-In other words,
-if a new release of the software includes changes to the documentation,
-then the documentation package MUST also be updated.
-But if the new version of the software
-does not include documentation changes,
-then you MAY choose not to update the documentation package.
-
-A comment SHOULD be added near Version tag of the main package
-to remind maintainers to update the separate *-doc package when needed.
-
-[#changelogs]
-== Changelogs
-
-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:
-
-[source, rpm-spec]
-----
-%changelog
-%autochangelog
-----
-
-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.
-
-[source]
-----
-Add README file (rhbz#1000042)
-----
-
-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 https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html[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 xref:manual-changelog.adoc[Manual Changelog].
-
-=== Example
-
-The packager updates package to version 1.0 and creates a commit
-
-----
-$ git show
-commit 0000000000001234567890ABCDEF000000000000
-Author: Joe Packager <joe@example.com>
-Date:   Wed Jun 14 2003
-
-    Version 1.0
-
-    ... (rhbz#1000024)
-    - Also fixes the slowdown reported in rhbz#1000025
-    - Upstream changelog: https://example.com/package/NEWS.html#v1.0
-
-    Whitespace in the spec file has been cleaned up.
-
-diff --git package.spec package.spec
-index 5c77064c03..efcd53a61c 100644
---- package.spec
-+++ package.spec
-@@ -1,5 +1,5 @@
- Name:           package
--Version:        0.1
-+Version:        0.2
- Release:        %autorelease
-...
-----
-
-When the package is built, an appropriate changelog entry will be generated.
-It can be previewed with `rpmautospec generate-changelog`:
-
-----
-$ rpmautospec generate-changelog
-* Wed Jun 14 2003 Joe Packager <joe@example.com> - 0.2-1
-- Version 1.0 (rhbz#1000024)
-- Also fixes the slowdown reported in rhbz#1000025
-- Upstream changelog: https://example.com/package/NEWS.html#v1.0
-----
-
-Note that the sentence about whitespace is not included in the changelog.
-
-
-== Manpages
-
-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:
-
-[source, rpm-spec]
-----
-%files
-%{_mandir}/man1/foo.1*
-----
-
-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>>.
-
-[#compiler]
-== Compiler
-
-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:
-
-* The default compiler cannot build a package correctly.
-* The packager needs to disable a compiler feature (e.g. LTO)
-in order for the default compiler to correctly compile their package.
-* The default compiler takes significantly longer to build a package.
-* The default compiler is missing a feature that would benefit the package.
-
-Packagers choosing to use a non-default compiler
-should document the reason for this decision in a comment in the spec file.
-
-== Compiler Macros
-
-If clang is being used to build a package,
-packagers must set the %toolchain macro to clang:
-
-[source, rpm-spec]
-----
-%global toolchain 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:
-
-[source, rpm-spec]
-----
-%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.
-The values of these variables are controled by setting the %toolchain macro
-to either clang or gcc.
-
-
-== Compiler Flags
-
-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, {cpp}, and Fortran code,
-the xref:RPMMacros.adoc#build-flags-macros-and-variables[%\{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.
-
-Packages SHOULD avoid editing the 'CFLAGS' etc. environment variables by hand,
-and instead use methods for compiler flags manipulation described in
-https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md[this documentation]
-
-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.
-
-=== PIE
-
-PIE adds security to executables
-by composing them entirely of position-independent code.
-Position-independent code (PIC) is machine instruction code
-that executes properly regardless of where in memory it resides.
-PIE allows Exec Shield to use address space layout randomization
-to prevent attackers from knowing where existing executable code is
-during a security attack using exploits that rely on knowing the offset
-of the executable code in the binary, such as return-to-libc attacks.
-
-In Fedora, PIE is enabled by default. To disable it in your
-spec, add:
-
-[source, rpm-spec]
-----
-%undefine _hardened_build
-----
-
-If your package meets any of the following criteria you
-MUST NOT disable the PIE compiler flags:
-
-* Your package is long running.
-This means it's likely to be started and keep running
-until the machine is rebooted, not start on demand and quit on idle.
-
-* Your package has suid binaries, or binaries with capabilities.
-
-* Your package runs as root.
-
-== Debuginfo Packages
-
-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,
-xref:Debuginfo.adoc[Packaging:Debuginfo].
-
-== Devel Packages
-
-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:
-
-* Header files (foo.h), usually found in /usr/include
-* Static library files
-when the package does not provide any matching shared library files.
-See <<packaging-static-libraries>> for more information about this scenario.
-* Unversioned shared system library files,
-when a matching versioned shared system library file is also present.
-For example, if your package contains:
-
-....
-   /usr/lib/libfoo.so.3.0.0
-   /usr/lib/libfoo.so.3
-   /usr/lib/libfoo.so
-....
-
-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.
-
-=== Unversioned Shared Objects
-
-As an additional complication,
-some software generates xref:Unversioned_shared_objects.adoc[unversioned shared objects]
-which are not intended to be used as system libraries.
-These files are usually plugins or modular functionality specific to an application,
-and are not to be located in the ld library paths or cache.
-These types of unversioned shared objects
-do not need to go into a -devel package.
-They are only loaded at runtime
-and should be included in a private directory of the main package.
-
-For specific details
-about how to deal with these types of DSOs,
-please see xref:Unversioned_shared_objects.adoc[unversioned shared objects]
-for detailed guidance.
-
-=== Exceptions
-
-There are some notable exceptions to this packaging model, specifically:
-
-* compilers often include development files in the main package
-because compilers are themselves only used for software development,
-thus, a split package model does not make any sense.
-
-When in doubt as to whether a file belongs in the base package or in -devel,
-packagers should consider whether the file is necessary to be present
-for a user to use or execute the functionality in the base package properly,
-or if it is only necessary for development.
-If it is only necessary for development, it must go into a -devel package.
-
-As with all Fedora Packaging Guidelines,
-it is recognized that there are unique situations
-that fall outside of the boundaries of this model.
-Should you come across such a case,
-please open a ticket with the {packaging-committee}
-and explain it to us so that we can extend the Guidelines to address it.
-
-=== Pkgconfig Files (`+foo.pc+`)
-
-The placement of pkgconfig(.pc) files depends on their usecase.
-Since they are almost always used for development purposes,
-they should be placed in a -devel package.
-A reasonable exception is when the main package itself is a development tool
-not installed in a user runtime, e.g. gcc or gdb.
-
-== Requiring Base Package
-
-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:
-
-[source, rpm-spec]
-----
-Requires: %{name}%{?_isa} = %{version}-%{release}
-----
-
-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.
-
-== Shared Libraries
-
-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.
-
-=== Listing Shared Library Files
-
-Shared libraries installed directly into `+%{_libdir}+` *SHOULD NOT* be listed
-in the `%files` section of the spec by using a glob in a way
-that conceals important parts of the file name (e.g. `libfoo.so*`),
-since changes to the `SONAME` also result in a changed file name in most cases.
-
-Otherwise, when the library bumps its `SONAME` as part of an update,
-this change might remain unnoticed and cause problems like broken dependencies
-(see the relevant {updates-policy} section for further information).
-
-However, if the use of globs is deemed useful by the packager - for example,
-if the `Y` and `Z` parts of a library named `libfoo.so.X.Y.Z` change frequently,
-using something like `libfoo.so.X{,.*}` is recommended instead,
-since dependent packages usually don't have to be rebuilt
-for changes of this kind.
-
-=== Downstream `+.so+` Name Versioning
-
-In cases where upstream ships unversioned .so *library*
-(so this is not needed for plugins, drivers, etc.),
-the packager *MUST* try to convince upstream to start versioning it.
-
-If that fails due to unwilling or unresponsive upstream,
-the packager may start versioning downstream
-but this must be done with caution and ideally only in rare cases.
-We don't want to create a library that could conflict with upstream
-if they later start providing versioned shared libraries.
-Under no circumstances should the unversioned library be shipped in Fedora.
-
-For downstream versioning, the name should be composed like this:
-
-....
-libfoobar.so.0.n
-....
-
-The _n_ should initially be a small integer (for instance, "1").
-we use two digits here ("0.n")
-because the common practice with upstreams is to use only a single digit here.
-Using multiple digits helps us avoid potential future conflicts.
-Do not forget to add the SONAME field (see below) to the library.
-
-When new versions of the library are released,
-you should use an {abi-comparison-tool} to check for ABI differences
-in the built shared libraries.
-If it detects any incompatibilities, bump the _n_ number by one.
-
-==== SONAME Handling
-
-When running an executable linked to shared object with SONAME field,
-the dynamic linker checks for this field
-instead of filename to determine the object with which it should link.
-This allows developers to simply link against the unversioned library symlink
-and the dynamic linker will link against the correct object.
-
-Keep in mind that although the filename is usually the library's SONAME
-plus an incrementing minor version
-there's nothing that intrinsically links these.
-ldconfig uses the SONAME as the value for a symlink to the actual filename.
-The dynamic linker then uses that symlink to find the library,
-disregarding the actual filename.
-The dynamic linker merely does a simple equality check on the field
-and does not check for ABI incompatibilities or similar problems.
-This is the main reason for using an
-{abi-comparison-tool} and incrementing the SONAME.
-
-The SONAME field is written to the shared object by linker,
-using (at least in case of `+ld+`) the `+-soname SONAME+` flags.
-This can be passed as an option to `+gcc+` like this:
-
-....
-$ gcc $CFLAGS -Wl,-soname,libfoo.so.0.n -o libfoo.so.0.n
-....
-
-If you want to check if the SONAME field is set and what value it has,
-use the `+objdump+` command (from `+binutils+`):
-
-....
-$ objdump -p /path/to/libfoo.so.0.n | grep 'SONAME'
-....
-
-[#packaging-static-libraries]
-== Packaging Static 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.
-
-=== Packaging Static Libraries
-
-* In general, packagers SHOULD NOT ship static libraries.
-
-* We want to be able to track which packages are using static libraries
-(so we can find which packages need to be rebuilt
-if a security flaw in a static library is fixed, for instance).
-There are two scenarios in which static libraries are packaged:
-
-1.  *Static libraries and shared libraries.*
-In this case, the static libraries MUST be placed in a _*-static_ subpackage.
-Separating the static libraries from the other development files
-in _*-devel_ allow us to track this usage by checking which packages
-`+BuildRequire+` the _*-static_ package.
-The intent is that whenever possible,
-packages will move away from using these static libraries,
-to the shared libraries.
-If the _*-static_ subpackage requires headers or other files
-from _*-devel_ in order to be useful it MUST require the _*-devel_ subpackage.
-2.  *Static libraries only.*
-When a package only provides static 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:
-+
-[source, rpm-spec]
-----
-%package devel
-Provides: foo-static = %{version}-%{release}
-----
-
-Packages which explicitly need to link against the static version
-MUST `+BuildRequire: foo-static+`,
-so that the usage can be tracked.
-
-* If (and only if) a package has shared libraries
-which require static libraries to be functional,
-the static libraries can be included in the _*-devel_ subpackage.
-The devel subpackage must have a virtual Provide for the _*-static_ package,
-and packages dependent on it must `+BuildRequire+` the _*-static_ package.
-
-=== Packaging Header Only Libraries
-
-Certain libraries, especially some {cpp} template libraries,
-are header only libraries.
-Since the code is generated during compile time,
-they act just like static libraries and need to be treated as such.
-
-Place all of the header files in the _*-devel_ subpackage
-and then you must have a virtual Provide for the _*-static_ package:
-
-[source, rpm-spec]
-----
-%package devel
-Provides: foo-static = %{version}-%{release}
-----
-
-Packages which use the header library must `+BuildRequire: foo-static+`,
-so that the usage can be tracked.
-
-==== Use noarch only in subpackages
-
-The base package for a header library MUST NOT be marked noarch.
-This ensures that any tests are run on all architectures,
-and makes it possible to detect whether the build or install process
-has modified the headers based on the build architecture.
-
-When the contents of subpackages, including the `+-devel+` package,
-are actually architecture-independent, they may still be marked noarch.
-Since the base package for a header library typically has no `+%files+` list,
-this may result in an arched package that builds only noarch rpms.
-This may require adding `+%global debug_package %{nil}+` to the spec file in
-order to avoid empty `+debugsourcefiles.list+` issues.
-
-=== Statically Linking Executables
-
-Executables and libraries SHOULD NOT be linked statically against libraries
-which come from other packages.
-(It is of course acceptable for files generated
-during a package's build process
-to be linked statically against `+.a+` files
-generated as part of that build process.)
-
-If it is necessary to link against `+.a+` files from a different package,
-a build dependency on the `+-static+` package
-(not just the `+-devel+` package)
-which provides those files MUST be present so that the usage can be tracked.
-
-[#bundling]
-== Bundling and Duplication of System Libraries
-
-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:
-
-* If the bundled package also exists separately in the distribution,
-use the name of that package.
-Otherwise consult the xref:Naming.adoc[Naming Guidelines]
-to determine an appropriate name for the library
-as if it were entering the distribution as a separate package.
-
-* Use the xref:Versioning.adoc[Versioning Guidelines]
-to determine an appropriate version for the library, if possible.
-If the library has been forked from an upstream,
-use the upstream version that was most recently merged in or rebased onto,
-or the version the original library carried at the time of the fork.
-
-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.
-
-=== Avoid Bundling of Fonts in Other Packages
-
-Fonts in general-purpose formats such as
-Type1, OpenType TT (TTF) or OpenType CFF (OTF)
-are subject to specific packaging guidelines
-(xref:FontsPolicy.adoc[Packaging/FontsPolicy]),
-and should always be packaged in the system-wide font repositories
-instead of private application directories.
-For more information, see: xref:FontsPolicy.adoc[Packaging/FontsPolicy].
-
-== Beware of `+rpath+`
-
-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:
-
-[source, rpm-spec]
-----
-%__arch_install_post          \
-/usr/lib/rpm/check-rpaths     \
-/usr/lib/rpm/check-buildroot
-----
-
-When _check-rpaths_ is run, you might see output like this:
-
-....
-ERROR   0001: file '/usr/bin/xapian-tcpsrv' contains a standard rpath '/usr/lib64' in [/usr/lib64]
-....
-
-Any rpath flagged by check-rpaths *MUST* be removed.
-
-=== `+rpath+` for Internal Libraries
-
-When a program installs internal libraries
-they are often not installed in the system path.
-These internal libraries are only used for the programs
-that are present in the package
-(for example, to factor out code that's common to the executables).
-These libraries are not intended for use outside of the package.
-When this occurs, it is acceptable for the programs within the package
-to use an rpath to find these libraries.
-
-Example:
-
-....
-# Internal libraries for myapp are present in:
-%{_libdir}/myapp/
-%{_libdir}/myapp/libmyapp.so.0.3.4
-%{_libdir}/myapp/libmyapp.so
-
-# myapp has an rpath to %{_libdir}/myapp/
-readelf -d /usr/bin/myapp | grep RPATH
- 0x0000000f (RPATH)                      Library rpath: [/usr/lib/myapp]
-....
-
-TIP: *Non-Internal Libraries*: When programs outside of the package
-are supposed to link against the library,
-it is better to use the
-<<alternatives-to-rpath,Alternative to Rpath>>
-or simply move the libraries into `+%{_libdir}+` instead.
-That way the dynamic linker can find the libraries
-without having to link all the programs with an rpath.
-
-[#alternatives-to-rpath]
-=== Alternatives to `+rpath+`
-
-Often, rpath is used because a binary is looking for libraries
-in a non-standard location
-(standard locations are /lib, /usr/lib, /lib64, /usr/lib64).
-If you are storing a library in a non-standard location (e.g. /usr/lib/foo/),
-you should include a custom config file in /etc/ld.so.conf.d/.
-For example, if I was putting 32 bit libraries of libfoo in /usr/lib/foo,
-I would want to make a file called "foo32.conf"
-in /etc/ld.so.conf.d/, which contained the following:
-
-....
-/usr/lib/foo
-....
-
-Make sure that you also make a 64bit version of this file (e.g. foo64.conf)
-as well (unless the package is disabled for 64bit architectures, of course).
-
-=== Removing `+rpath+`
-
-There are several different ways to fix the rpath issue:
-
-* If the application uses configure,
-try passing the _--disable-rpath_ flag to configure.
-* If the application uses a local copy of libtool,
-add the following lines to the spec after %configure:
-
-[source, rpm-spec]
-----
-%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.
-This is not always easy or sane to do, however.
-* As a last resort, Fedora has a package called _chrpath_.
-When this package is installed,
-you can run `+chrpath --delete+` on the files which contain rpaths.
-So, in our earlier example, we'd run:
-
-....
-chrpath --delete $RPM_BUILD_ROOT%{_bindir}/xapian-tcpsrv
-....
-
-Make sure that you remember to add a
-*BuildRequires: chrpath* if you end up using this method.
-
-== Configuration Files
-
-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.
-
-=== Configuration of Package Managers
-
-Packages MUST NOT install repository configuration files which violate
-the https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/[Third Party Repository Policy],
-unless those files are installed under `+%{_docdir}+`.
-
-== Per-Product Configuration
-
-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
-xref:Per-Product_Configuration.adoc[Per-Product Configuration Guidelines]
-for instructions on how to create packages
-that need to behave differently between Fedora.next Products.
-
-== Initscripts
-
-SystemV-style initscripts are forbidden in Fedora.
-Systemd units must be used instead.
-
-== Systemd Units
-
-Detailed guidelines for packaging systemd units
-and systemd-managed services are xref:Systemd.adoc[here].
-
-== Desktop Files
-
-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
-https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html[desktop-entry-spec],
-paying particular attention to validating correct usage of
-Name, GenericName,
-https://standards.freedesktop.org/menu-spec/latest/apa.html[Categories],
-https://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt[StartupNotify]
-entries.
-
-=== Icon Tag in Desktop Files
-
-The icon tag can be specified in two ways:
-
-* Full path to specific icon file:
-
-`+Icon=/usr/share/pixmaps/comical.png+`
-
-* Short name without file extension:
-
-`+Icon=comical+`
-
-The short name without file extension is preferred,
-because it allows for icon theming
-(it assumes .png by default, then tries .svg and finally .xpm),
-but either method is acceptable.
-
-=== `+.desktop+` File Creation
-
-If the package doesn't already include and install its own .desktop file,
-you need to make your own.
-You can do this by including a .desktop file you create as a Source:
-(e.g. Source3: %\{name}.desktop)
-or generating it in the spec file.
-Here are the contents of a sample .desktop file (comical.desktop):
-
-....
-[Desktop Entry]
-Name=Comical
-GenericName=Comic Archive Reader
-Comment=Open .cbr & .cbz files
-Exec=comical
-Icon=comical
-Terminal=false
-Type=Application
-Categories=Graphics;
-....
-
-=== `+desktop-file-install+` Usage
-
-It is not simply enough to just include the .desktop file in the package,
-one MUST run `+desktop-file-install+` (in `+%install+`)
-OR `+desktop-file-validate+` (in `+%check+` or `+%install+`)
-and have `+BuildRequires: desktop-file-utils+`,
-to help ensure .desktop file safety and spec-compliance.
-`+desktop-file-install+` MUST be used if the package does not install the file
-or there are changes desired to the .desktop file
-(such as add/removing categories, etc).
-`+desktop-file-validate+` MAY be used instead
-if the .desktop file's content/location does not need modification.
-Here are some examples of usage:
-
-[source, rpm-spec]
-----
-desktop-file-install                                    \
---dir=%{buildroot}%{_datadir}/applications              \
-%{SOURCE3}
-----
-
-[source, rpm-spec]
-----
-desktop-file-install                                    \
---add-category="AudioVideo"                             \
---delete-original                                       \
---dir=%{buildroot}%{_datadir}/applications              \
-%{buildroot}/%{_datadir}/applications/foo.desktop
-----
-
-[source, rpm-spec]
-----
-desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
-----
-
-Do *not* apply a vendor tag to .desktop files (using --vendor).
-
-== AppData Files
-
-Packages containing graphical applications should include AppData files.
-See xref:AppData.adoc[Packaging:AppData] for the relevant guidelines.
-
-== Macros
-
-Packagers are strongly encouraged to use macros
-instead of hard-coded directory names (see xref:RPMMacros.adoc[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:
-
-* The package must be consistent.
-For any given path, within the same spec,
-use either a hard-coded path or a macro, not a combination of the two.
-* %\{_libdir} must always be used for binary libraries due to multi-lib,
-you may not substitute a hard-coded path.
-
-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:
-
-....
-rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"
-....
-
-=== `+%autosetup+`
-
-As an alternative to the usual `+%setup+` macro,
-the `+%autosetup+` can be used.
-In addition to the normal %setup tasks,
-it will apply all defined Patch# items in the spec automatically.
-It is also capable of handling VCS formatted patch files,
-but this will require additional BuildRequires,
-and assumes that _all_ patch files in the spec are formatted
-for that single VCS type.
-For this reason, it is not recommended that you specify a VCS
-with `+%autosetup+`.
-For more details on proper use of `+%autosetup+`,
-refer to the
-https://rpm-software-management.github.io/rpm/manual/autosetup.html[RPM documentation].
-
-=== Using `+%{buildroot}+` and `+%{optflags}+` vs `+$RPM_BUILD_ROOT+` and `+$RPM_OPT_FLAGS+`
-
-There are two styles of defining the rpm Build Root and Optimization Flags
-in a spec file:
-
-|==========================================
-|           |macro style   |variable style
-|Build Root |%\{buildroot} |$RPM_BUILD_ROOT
-|Opt. Flags |%\{optflags}  |$RPM_OPT_FLAGS
-|==========================================
-
-There is very little value in choosing one style over the other,
-since they will resolve to the same values in all scenarios.
-You should pick a style and use it consistently throughout your packaging.
-
-Mixing the two styles, while valid,
-is bad from a QA and usability point of view,
-and should not be done in Fedora packages.
-
-=== Why the `+%makeinstall+` Macro Should Not Be Used
-
-Fedora's RPM includes a `+%makeinstall+` macro
-but it must *NOT* be used when make install DESTDIR=%\{buildroot} works.
-%makeinstall is a kludge that can work with Makefiles
-that don't make use of the DESTDIR variable
-but it has the following potential issues:
-
-* `+%makeinstall+` overrides a set of Make variables during "make install"
-and prepends the %\{buildroot} path,
-i.e. it performs
-make prefix="%\{buildroot}%\{_prefix}" libdir="%\{buildroot}%\{_libdir} ...".
-* It is error-prone and can have unexpected effects
-when run against less than perfect Makefiles,
-e.g., the buildroot path may be included in installed files
-where variables are substituted at install-time.
-* It can trigger unnecessary and wrong rebuilds when executing "make install",
-since the Make variables have different values compared with the %build section.
-* If a package contains libtool archives,
-it can cause broken *.la files to be installed.
-
-Instead, Fedora packages should use: `+%make_install+` (Note the "_" !),
-`+make DESTDIR=%{buildroot} install+`
-or `+make DESTDIR=$RPM_BUILD_ROOT install+`.
-Those all do the same thing.
-
-=== Source RPM Buildtime Macros
-
-All macros in `+Summary:+` and `+%description+`
-need to be expandable at srpm buildtime.
-Because SRPMs are built without the package's BuildRequires installed,
-depending on macros defined outside of the spec file
-can easily lead to the unexpanded macros showing up in the built SRPM.
-One way to check is to create a minimal chroot and build the srpm:
-
-....
-mock --init
-mock --copyin [SRPM] /
-mock --shell bash
-rpm -ivh [SRPM]
-cd /builddir/build/SPECS
-rpmbuild -bs --nodeps [SRPM]
-rpm -qpiv /builddir/build/SRPMS/[SRPM]
-....
-
-Check the `+rpm+` output for unexpanded macros (`+%{foo}+`)
-or missing information (when`+%{?foo}+` is expanded to the empty string).
-Even easier is to simply avoid macros in `+Summary:+` and `+%description+`
-unless they are defined in the current spec file.
-
-=== Improper Use of `+%_sourcedir+`
-
-Packages which use files itemized as Source# files,
-must refer to those files by their `+Source#+` macro name,
-and must not use `+$RPM_SOURCE_DIR+` or `+%{sourcedir}+`
-to refer to those files.
-See xref:RPM_Source_Dir.adoc[Packaging:RPM_Source_Dir] for full details.
-
-=== Software Collection Macros
-
-{scl-guidelines} are to be kept to separate packages from mainstream packages
-similar to how xref:MinGW.adoc[MingW packages] are managed.
-
-In the past, SCL macros were allowed to be present
-inside of mainstream packages if they were not used.
-Since we're now building SCLs, we are now enforcing a strict separation.
-Packages *MUST* be updated to restrict SCL macros
-to only those packages particularly approved as part of an SCL.
-
-=== Packaging of Additional RPM Macros
-
-Additional RPM macros must be stored in %\{_rpmmacrodir}.
-They must be named using the syntax "macros.$PACKAGE" (e.g. macros.perl).
-
-Normally, these files are packaged in the -devel subpackage,
-since they are usually only needed for building other packages.
-However, in some situations, this is not always ideal
-and packagers are encouraged to use their best judgment
-when determining the proper package for these files.
-RPM macro files MUST NOT be marked as `+%config+`.
-
-== Scripting Inside of Specfiles
-
-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:
-
-* Python
-* Perl
-* Standard programs used in shell programing, for instance gawk or sed
-* Lua (as supported by the native lua interpreter in rpm)
-
-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.
-
-== `+%global+` Preferred Over `+%define+`
-
-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.
-
-[#handling_locale_files]
-== Handling Locale Files
-
-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
-
-[source, rpm-spec]
-----
-BuildRequires: gettext
-----
-
-For Qt-based packages that use the Linguist tool chain,
-for the localization utilities add the appropriate qtX-linguist package
-
-[source, rpm-spec]
-----
-BuildRequires: qt6-linguist
-----
-
-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 xref:Langpacks.adoc[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:
-
-[source, rpm-spec]
-----
-%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.
-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+`.
-
-[source, rpm-spec]
-----
-%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
-
-[source, rpm-spec]
-----
-%find_lang %{name} --with-gnome
-----
-
-To process KDE help files put into `+/usr/share/doc/HTML/+` use
-
-[source, rpm-spec]
-----
-%find_lang %{name} --with-kde
-----
-
-To process Qt's `+.qm+` binary translation files use
-
-[source, rpm-spec]
-----
-%find_lang %{name} --with-qt
-----
-
-To process localised manpages
-(doesn't include the default, non-localised one), use
-
-[source, rpm-spec]
-----
-%find_lang %{name} --with-man
-----
-
-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":
-
-[source, rpm-spec]
-----
-Name: foo
-...
-%prep
-%setup -q
-
-%build
-%configure --with-cheese
-make %{?_smp_mflags}
-
-%install
-make DESTDIR=%{buildroot} install
-%find_lang %{name}
-%find_lang bar --with-man
-
-%files -f %{name}.lang -f bar.lang
-%license LICENSE
-%doc README
-%{_bindir}/%{name}
-%{_mandir}/man1/bar.1*
-
-%changelog
-* Fri Jan 13 2012 Karel Volny <kvolny@redhat.com> 0.1-2
-- add man pages example
-
-* 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?
-
-Using `+%find_lang+` helps keep the spec file simple,
-and helps avoid several other packaging mistakes.
-
-* Packages that use `+%{_datadir}/*+` to grab all the locale files in one line
-also grab ownership of the locale directories, which is not permitted.
-* Most packages that have locales have lots of locales.
-Using `+%find_lang+` is much easier in the spec file than having to do:
-
-[source, rpm-spec]
-----
-%{_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,
-preventing you from having to update the spec any more than is necessary.
-
-Keep in mind that usage of `+%find_lang+`
-in packages containing locales is a MUST
-unless the locale files are broken out into langpacks.
-In which case, you should follow xref:Langpacks.adoc[the langpack guidelines].
-
-== Log Files
-
-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).
-
-=== `+logrotate+` Config File
-
-Logrotate config files should be named in a way that matches
-the daemon/software which is generating the logs,
-which is usually (though not always) the same name as the package.
-When unsure, use "%\{name}.conf".
-These files must be placed in %\{_sysconfdir}/logrotate.d,
-and should use standard file permissions (0644) and ownership (root:root).
-
-Since these are config files,
-they must be marked as %config(noreplace) in the %files list.
-
-==== Example Minimal `+logrotate+` Config File
-
-....
-/var/log/example/*log {
-    missingok       # If the log file is missing, go on to the next one without issuing an error message
-    notifempty      # Don't do any rotation if the logfile is empty
-    compress        # Compress older files with gzip
-    delaycompress       # Don't compress yesterdays files
-}
-....
-
-== Timestamps
-
-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+`.
-
-== Parallel Make
-
-Whenever possible, invocations of `+make+` should be done as
-
-[source, rpm-spec]
-----
-%make_build
-----
-
-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
-
-[source, rpm-spec]
-----
-%_smp_mflags -j3
-----
-
-to your `+~/.rpmmacros+` file -- even on UP machines --
-as this will expose most of these errors.
-
-== Scriptlets
-
-Packages may contain pieces of run-time code that are triggered during DNF transactions.
-These are called sriptlets and are documented xref:Scriptlets.adoc[here].
-
-== Build Scripts
-
-Build scripts of the packages
-(%prep, %build, %install, %check and %clean)
-may only alter files (create, modify, delete) under
-%\{buildroot}, %\{_builddir}
-and valid temporary locations like /tmp, /var/tmp
-(or $TMPDIR or %\{_tmppath} as set by the rpmbuild process)
-according to the following matrix
-
-[cols=",,,",]
-|=============================================================================
-|         |/tmp, /var/tmp, $TMPDIR, %\{_tmppath} |%\{_builddir} |%\{buildroot}
-|%prep    |yes                                   |yes           |no
-|%build   |yes                                   |yes           |no
-|%install |yes                                   |yes           |yes
-|%check   |yes                                   |yes           |no
-|%clean   |yes                                   |yes           |yes
-|=============================================================================
-
-Further clarification: That should hold true irrespective of the builder's uid.
-
-== Build Packages with Separate User Accounts
-
-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.
-
-== Relocatable Packages
-
-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.
-
-== File and Directory Ownership
-
-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:
-
-* The packages sharing ownership of the identical files
-are built from a single SRPM.
-
-OR
-
-* The packages sharing ownership of the identical files
-are not in a dependency chain
-(e.g. if package A requires package B,
-they should not both contain identical files,
-either A or B must own the common files, but not both.)
-
-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
-xref:LicensingGuidelines.adoc#subpackage-licensing[Subpackage Licensing].
-
-Directory ownership is a little more complex than file ownership.
-Packages must own all directories they put files in, except for:
-
-* any directories owned by the `+filesystem+`, `+man+`,
-or other explicitly created `+-filesystem+` packages
-* any directories owned by other packages
-in your package's natural dependency chain
-
-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 xref:UnownedDirectories.adoc[Packaging:UnownedDirectories]
-for the details.
-
-IMPORTANT: When co-owning directories,
-you *must* ensure that the ownership and permissions
-on the directory match in all packages that own it.
-
-Here are examples that describe how to handle most cases
-of directory ownership.
-
-=== The directory is wholly contained in your package, or involves core functionality of your package
-
-An example:
-
-....
-gnucash places many files under the /usr/share/gnucash directory
-....
-
-Solution: the `+gnucash+` package should own
-the `+/usr/share/gnucash+` directory
-
-=== The directory is also owned by a package implementing required functionality of your package
-
-An example:
-
-....
-pam owns the /etc/pam.d directory
-gdm places files into /etc/pam.d
-gdm depends on pam to function normally, and would Require: pam (either implicitly or explicitly) separate from the directory ownership.
-....
-
-Solution: the `+pam+` package should own the `+/etc/pam.d+` directory,
-and `+gdm+` should `+Require:+` the `+pam+` package.
-
-=== The directory is owned by a package which is not required for your package to function
-
-Some packages create and own directories
-with the intention of permitting other packages to store appropriate files,
-but those other packages do not need that original package
-to be present to function properly.
-
-An example:
-
-....
-gtk-doc owns the /usr/share/gtk-doc/ directory
-evolution puts files into /usr/share/gtk-doc/
-evolution does not need gtk-doc in order to function properly.
-Nothing in evolution's dependency chain owns /usr/share/gtk-doc/
-....
-
-Solution: the `+evolution+` package should own the
-`+/usr/share/gtk-doc+` directory.
-There is no need to add an explicit Requires on gtk-doc
-solely for the directory ownership.
-
-Sometimes, it may be preferable for such directories to be owned
-by an "artificial filesystem" package, such as `+mozilla-filesystem+`.
-These packages are designed to be explicitly required
-when other packages store files in their directories,
-thus, in such situations,
-these packages should explicitly Require the artificial filesystem package
-and not multiply own those directories.
-Packagers should consider the number of
-affected directories and packages
-when determining whether to create artificial filesystem packages,
-and use their own best judgement to determine if this is necessary or not.
-
-TIP: *Rule of Thumb*: When determining whether this exception applies,
-packagers and reviewers should ask this question:
-Do the files in this common directory enhance
-or add functionality to another package,
-where that other package is not necessary to be present
-for the primary functionality of this package?
-
-=== The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version
-
-An example involving Perl modules:
-
-Assume `+perl-A-B+` depends on `+perl-A+`
-and installs files into
-/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B.
-The base Perl package guarantees that it will own
-/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
-for as long as it remains compatible with version 5.8.8,
-but a future upgrade of the `+perl-A+` package may install into
-(and thus own)
-/usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A.
-So the `+perl-A-B+` package needs to own
-/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A
-as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B
-in order to maintain proper ownership.
-
-=== File Permissions
-
-Permissions on files MUST be set properly.
-Inside of /usr, files should be owned by root:root
-unless a more specific user or group is needed for security.
-They MUST be universally readable (and executable if appropriate).
-Outside of /usr, non-config and non-state files SHOULD be owned by root:root,
-universally readable (and executable if appropriate)
-unless circumstances require otherwise.
-
-The default file mode is 0644 or 0755.
-Directories should be mode 0755.
-Most well behaved build scripts and rpm will use these defaults.
-If the directory needs to be group writable,
-it SHOULD also have the setgid bit set
-so that files written there are owned by that group.
-These directories SHOULD have mode 2775.
-
-The %defattr directive in the %files list
-SHOULD ONLY be used when setting a non-default value,
-or to reset to the default value after having set a non-default value.
-
-=== Explicit lists
-
-Packagers *SHOULD NOT* simply glob everything under a shared directory.
-
-In particular, the following *SHOULD NOT* be used in `+%files+`:
-
-* `+%{_bindir}/*+`
-* `+%{_datadir}/*+`
-* `+%{_includedir}/*+`
-* `+%{_mandir}/*+`
-* `+%{_docdir}/*+`
-
-This rule serves as a check against common mistakes
-which are otherwise hard to detect.
-It does limit some possibilities for automation.
-
-The most common mistake this rule prevents is upstream adding new commands in `+%{_bindir}/*+`.
-You should always check such changes for
-https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_common_conflicting_files_cases_and_solutions[conflicts],
-and keep the list of such files explicit and auditable.
-
-== Users and Groups
-
-Some packages require or benefit from
-dedicated runtime user and/or group accounts.
-Guidelines for handling these cases are in a
-xref:UsersAndGroups.adoc[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
-
-Web applications packaged in Fedora should put their content into
-/usr/share/%\{name} and NOT into /var/www/.
-This is done because:
-
-* /var is supposed to contain variable data files and logs.
-/usr/share is much more appropriate for this.
-* Many users already have content in /var/www,
-and we do not want any Fedora package to step on top of that.
-* /var/www is no longer specified by the Filesystem Hierarchy Standard
-
-== Conflicts
-
-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:
-xref:Conflicts.adoc[Conflicts].
-
-Tools such as Alternatives and Environment Modules
-can also help prevent package conflicts.
-
-=== Alternatives
-
-The "alternatives" tool provides a means for parallel installation of packages
-which provide the same functionality by maintaining sets of symlinks.
-For full details on how to properly use alternatives,
-see xref:Alternatives.adoc[Alternatives].
-
-=== Environment Modules
-
-When there are multiple variants that each serve the needs of some user
-and thus must be available simultaneously by users,
-the alternatives system simply isn't enough since it is system-wide.
-In such situations, use of Environment Modules can avoid conflicts.
-For full details on how to properly use Environment Modules,
-see xref:EnvironmentModules.adoc[Environment Modules].
-
-== Patch Guidelines
-
-=== All patches should have an upstream bug link or comment
-
-All patches in Fedora spec files *SHOULD* have a comment above them
-about their upstream status.
-Any time you create a patch,
-it is best practice to file it in an upstream bug tracker,
-and include a link to that in the comment above the patch.
-For example:
-
-[source, rpm-spec]
-----
-# 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:
-
-[source, rpm-spec]
-----
-# 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
-(https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/[Staying Close to Upstream Projects]).
-It will help others (and even you) down the line in package maintenance
-by knowing what patches are likely to appear in a new upstream release.
-
-==== If upstream doesn't have a bug tracker
-
-You can indicate that you have sent the patch upstream and any known status:
-
-[source, rpm-spec]
-----
-# Sent upstream via email 20080407
-Patch: foobar-fix-the-bar.patch
-----
-
-[source, rpm-spec]
-----
-# 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:
-
-[source, rpm-spec]
-----
-# This patch is temporary until we land the long term System.loadLibrary fix in OpenJDK
-Patch: jna-jni-path.patch
-----
-
-=== Applying Patches
-
-Normally, patches to a package SHOULD be listed in `+PatchN:+` tags
-in the RPM spec file and applied using the %patch or %autosetup macros.
-The files MUST then be checked into the Fedora Package revision control system
-(currently the git repos on pkgs.fedoraproject.org
-and commonly accessed via fedpkg).
-Storing the files in this way allows people to use standard tools
-to visualize the changes between revisions of the files
-and track additions and removals
-without a layer of indirection (as putting them into lookaside would do).
-
-Applying patches directly from RPM_SOURCE_DIR IS NOT ALLOWED.
-Please see
-xref:RPM_Source_Dir.adoc[Packaging:RPM_Source_Dir] for the complete rationale.
-
-The maintainer MAY deviate from this rule
-when the upstream of the package provides an extremely large patch
-or a tarball of patches against a base release.
-In this case the tarball of patches MAY be listed as a `+SourceN:+` line
-and the patches would be applied by untarring the archive
-and then applying the distributed patch(es)
-using the regular /usr/bin/patch command.
-Additional patches to the package
-(for instance, generated by the Fedora maintainer to fix bugs)
-MUST still be listed in `+PatchN:+` lines
-and be applied by %patch macros
-after the patches from the tarball were applied.
-Maintainers and reviewers should be cautious when exercising this exception
-as shipping an update as a patchset
-may be a sign that the patchset is not from the actual upstream
-or that the patches should be reviewed for correctness
-rather than simply accepted as the upstream code base.
-
-== Use of Epochs
-
-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:
-
-[source, rpm-spec]
-----
-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.
-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:
-
-[source, rpm-spec]
-----
-Requires: foo = %{epoch}:%{version}-%{release}
-----
-
-=== Epochs from Third Party Repositories
-
-If a package to be imported is or previously was present
-in a publicly accessible repository,
-the packager can optionally include an Epoch tag
-equal to that of the most recent version of the third-party package.
-
-== Symlinks
-
-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.
-
-=== Relative Symlinks
-
-A relative symlink is a symlink which points to a file or directory
-relative to the position of the symlink.
-For example, this command would create a relative symlink:
-
-....
-ln -s ../..%{_bindir}/foo %{buildroot}%{_bindir}/bar
-....
-
-Pros:
-
-* Relative symlinks will point to the same file inside or outside of a chroot.
-
-Cons:
-
-* Much more complicated to create than absolute symlinks
-* Relative symlinks may break or behave unexpectedly
-when a part of a filesystem is mounted to a custom location.
-* Relative symlinks may break when bind mounting or symlinking directories.
-* Relative symlinks may make it more difficult to use rpm system macros.
-
-=== Absolute Symlinks
-
-An absolute symlink is a symlink which points to an absolute file
-or directory path.
-For example, this command would create an absolute symlink:
-
-....
-ln -s %{_bindir}/foo %{buildroot}%{_bindir}/bar
-....
-
-Pros:
-
-* Much easier to create than relative symlinks.
-* Absolute symlinks work properly when bind mounting or symlinking directories.
-* Absolute symlinks work well with rpm system macros.
-
-Cons:
-
-* Absolute symlinks may break when used with chroots.
-
-== Replacing a Symlink to a Directory or a Directory to Any Type File
-
-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 xref:Directory_Replacement.adoc[Packaging:Directory_Replacement]
-for information about doing this.
-
-== Test Suites
-
-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.
-
-== tmpfiles.d
-
-There are specific guidelines for handling tmpfiles.d
-configurations and directories
-(in /run and /run/lock): xref:Tmpfiles.d.adoc[Tmpfiles.d].
-
-[#renaming-or-replacing-existing-packages]
-== Renaming/Replacing or Removing Existing Packages
-
-NOTE: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/[Package Renaming Process]
-should be followed when renaming an existing package.
-
-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:
-
-[source, rpm-spec]
-----
-Provides: oldpackagename = $provEVR
-Obsoletes: oldpackagename < $obsEVR
-----
-
-$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.
-
-CAUTION: *Take `+%{?dist}+` into account*:
-When deciding what $obsEVR should be,
-remember that it needs to be higher than the previous `Release:`,
-including the `+%{?dist}+` suffix.
-Example: if the package previously had the release tag of `+-4.fcNN+`,
-the release specified in $obsEVR should be at least 5.
-
-NOTE: If the replaced package uses `rpmautospec`,
-either look at the built package (e.g. in koji) to find the actual release tag of the latest build,
-or use `+rpmautospec calculate-release+` to calculate just the release number.
-
-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
-https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=fedora-obsolete-packages[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):
-
-[source, rpm-spec]
-----
-Provides: foo = 2:%{version}-%{release}
-# Important: We set the Obsoletes release to 4 to be higher than the last build of foo
-Obsoletes: foo < 2:1.0-4
-----
-
-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.
-
-=== One-to-Many Replacement
-
-Sometimes a package is split into two or more packages
-(either subpackages or separate source packages)
-to make some components optional,
-but users of the optional parts shall be able to upgrade
-without losing the functionality.
-Thus the new packages need to be pulled in
-on upgrade from a version before the split.
-If some are later removed,
-they shall not be pulled in again on further upgrades.
-
-This is achieved by putting an `+Obsoletes:+` tag like above
-in each of the packages that together replace the original package.
-If the name of the original package still exists after the split,
-that package needs to obsolete itself.
-Even if an optional split-out package requires the original package,
-the original package still must obsolete itself.
-Otherwise the split-out package won't be pulled in.
-
-Example: Foo version 3 contains Bar as a non-essential component.
-In version 4, Bar is moved to a subpackage.
-Bar shall not disappear on upgrade.
-
-[source, rpm-spec]
-----
-Name:      foo
-Version:   4
-Release:   1%{?dist}
-Obsoletes: foo < 4
-
-%package bar
-Requires:  foo%{?_isa} = %{version}-%{release}
-Obsoletes: foo < 4
-----
-
-NOTE: Packages pulled in this way are not marked as user-installed by DNF 4,
-so `+dnf autoremove+` will remove them.
-This appears to be fixed in DNF 5.
-
-== Deprecating Packages
-
-A procedure exists for indicating that a package is deprecated
-and may leave the distribution in the future.
-See xref:deprecating-packages.adoc[Deprecating Packages].
-
-== Networking Support
-
-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.
-
-== Cron Files
-
-For details on how to package cron files, refer to:
-xref:CronFiles.adoc[CronFiles].
-
-== Security Updates to Resolve Known CVE Issues
-
-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.
-
-== Build Time Network Access
-
-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.
-
-[#bootstrapping]
-== Bootstrapping
-
-If your package introduces build time circular dependencies,
-you should use this macro to bootstrap your package:
-
-[source, rpm-spec]
-----
-# When we are bootstrapping, we drop some dependencies, and/or build time tests.
-%bcond_with bootstrap
-
-[...]
-
-%if %{without bootstrap}
-# dependencies for %%check
-BuildRequires: foo
-%endif
-
-[...]
-
-%if %{without bootstrap}
-%check
-make check
-%endif
-----
-
-TIP: Since Fedora 30,
-     as a nice side-effect,
-     when bootstrapping mode is enabled,
-     the `+~bootstrap+` suffix is appended to the dist tag.
-     This avoids the need to bump release
-     between bootstrap and final build.
-     You can temporarily enable bootstrapping by commit,
-     which changes `+%bcond_with bootstrap+` to `+%bcond_without bootstrap+`
-     and later reverting the commit to do final build.
-
-TIP: Since Fedora 31,
-     you can disable the automatic suffix addition
-     by specifying `+%global __bootstrap %{nil}+`
-     in your spec file.
-
-If your package explicitly `+Provides:+` some functionality
-that is missing when bootstrapped,
-then that `+Provides:+` should look like:
-
-[source, rpm-spec]
-----
-%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
-as stated in <<General Exception Policy>>.
-
-== System Cryptographic Policies
-
-Applications which make use the SSL or TLS cryptographic protocols
-MUST follow xref:CryptoPolicies.adoc[Crypto Policies].
-
-== Shebang Lines
-
-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:
-
-* `+env+`, `+/bin/env+` and `+/usr/bin/env+` MUST NOT be used.
-The interpreter used to run packaged applications cannot depend upon
-what the user has in their personal `+$PATH+`.
-* Files which are not installed as executables SHOULD NOT have shebang lines.
-* Language-specific guidelines may have additional restrictions.
-
-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:
-
-* The packager can elect to fix the shebang lines manually
-(using patches, scripting via sed, or other similar methods).
-* The packager can remove the executable permission from the script
-so that the checks and modifications are not made.
-
-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
-xref:AutoProvidesAndRequiresFiltering.adoc[Packaging:AutoProvidesAndRequiresFiltering].
-It is also possible to disable the functionality entirely
-by adding `+%undefine __brp_mangle_shebangs+`
-near the beginning of the specfile.
-
-== BRP (BuildRoot Policy) Scripts
-
-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:
-
-[source, rpm-spec]
-----
-# 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.
-For a list of the BRP scripts run by default,
-invoke:
-
- sed -r -n '/^%.?__os_install_post/,/%.?nil/p' /usr/lib/rpm/redhat/macros
-
-For a list of all BRP scripts,
-invoke:
-
- rpmbuild --eval '%dump' |& grep ': __brp_'
-
-=== Removal of common sources of build irreproducibility
-
-One of the BRP scripts that is invoked by default is
-`+%__os_install_post_build_reproducibility+`.
-Its purpose is to normalize installed files
-by removing unwanted embedded metadata that is dependent on the build environment
-and may cause different builds from the same sources to be irreproducible.
-
-See `/usr/lib/rpm/macros.d/macros.build-reproducibility`
-for details about how it can be configured.
-
-== Packaging for EPEL
-
-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
-https://fedoraproject.org/wiki/EPEL:Packaging[the EPEL packaging guidelines]
-for additional information.
-
-== Domain Specific Guidelines
-
-Some applications, languages and build systems
-have specific guidelines written for them, located on their own pages:
-
-* xref:Ada.adoc[Ada]
-* xref:BLAS_LAPACK.adoc[BLAS/LAPACK]
-* xref:C_and_C++.adoc[C and {cpp}]
-* xref:CMake.adoc[CMake]
-* xref:D.adoc[D]
-* xref:Emacs.adoc[Emacs]
-* xref:FontsPolicy.adoc[Fonts]
-* xref:Fortran.adoc[Fortran]
-* xref:GAP.adoc[GAP]
-* xref:Haskell.adoc[Haskell]
-* xref:Java.adoc[Java]
-* xref:JavaScript.adoc[JavaScript]
-* xref:Langpacks.adoc[Language packs]
-* xref:LibreOfficeExtensions.adoc[LibreOffice Extensions]
-* xref:Lisp.adoc[Lisp]
-* xref:Meson.adoc[Meson]
-* xref:MinGW.adoc[MinGW]
-* xref:Mono.adoc[Mono]
-* xref:MPI.adoc[MPI]
-* xref:Node.js.adoc[Node.js]
-* xref:OCaml.adoc[OCaml]
-* xref:Octave.adoc[Octave]
-* xref:Perl.adoc[Perl]
-* xref:PHP.adoc[PHP]
-* xref:Python.adoc[Python]
-* xref:R.adoc[R]
-* xref:Ruby.adoc[Ruby]
-* xref:Rust.adoc[Rust]
-* xref:SugarActivityGuidelines.adoc[Sugar activities]
-* xref:Tcl.adoc[Tcl/Tk extensions]
-* xref:Tree-sitter.adoc[Tree-sitter parsers]
-* xref:Web_Assets.adoc[Web Assets]
-* xref:WordPress_plugin_packaging_guidelines.adoc[WordPress extensions]
diff --git a/guidelines/modules/ROOT/pages/manual-changelog.adoc b/guidelines/modules/ROOT/pages/manual-changelog.adoc
deleted file mode 100644
index 24494d6..0000000
--- a/guidelines/modules/ROOT/pages/manual-changelog.adoc
+++ /dev/null
@@ -1,119 +0,0 @@
-= Manual Changelog
-
-This describes the traditional method of managing changelogs that provides a
-separate text log of user-visible changes independently of the git commit messages.
-This is an alternative for the recommended method with `+%autochangelog+`
-described in xref:index.adoc#changelogs[Changelogs].
-
-_Every time_ you make changes, that is,
-whenever you increment the E-V-R of a package,
-add a changelog entry in the `+%changelog+` section.
-
-Changelog entries should provide a brief summary
-of the changes done to the package between releases.
-They must never simply contain an entire copy of the source `CHANGELOG` entries.
-The same general rules should be followed as described in
-xref:index.adoc#changelogs[Changelogs].
-
-You must use one of the following formats:
-
-[source, rpm-spec]
-----
-%changelog
-* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4
-- And fix the link syntax.
-----
-
-[source, rpm-spec]
-----
-%changelog
-* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4
-- And fix the link syntax.
-----
-
-[source, rpm-spec]
-----
-%changelog
-* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>
-- 0.6-4
-- And fix the link syntax.
-----
-
-If you wish to "scramble" or "obfuscate" your email address in the changelog,
-you may do so, provided that it is still understandable by humans.
-
-== Multiple Changelog Entries per Release
-
-In some situations, it may be useful for packagers
-to have multiple changelog entries in the spec file,
-but not increment the release field for each one.
-There are two supported methods for doing this:
-
-== Updating and replacing the existing date line
-
-In this situation, you have added this changelog entry,
-but have not built the package yet:
-
-[source, rpm-spec]
-----
-%changelog
-* 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:
-
-[source, rpm-spec]
-----
-%changelog
-* 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.
-
-You can do this any number of times,
-until you actually build 1.0-1 in the buildsystem.
-Once you've done that,
-you must change the E-V-R and any new entries should be added
-as described in
-xref:index.adoc#changelogs[Changelogs].
-
-== Repeat the old version release with a new entry
-
-In this situation, you have added this changelog entry,
-but have not built the package yet:
-
-[source, rpm-spec]
-----
-%changelog
-* 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:
-
-[source, rpm-spec]
-----
-%changelog
-* 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.
-
-You can do this any number of times,
-until you actually build 1.0-1 in the buildsystem.
-Once you've done that, you must change the E-V-R
-and any new entries should be added as described in
-xref:index.adoc#changelogs[Changelogs].
diff --git a/guidelines/modules/ROOT/pages/vpath.adoc b/guidelines/modules/ROOT/pages/vpath.adoc
deleted file mode 100644
index 0df660c..0000000
--- a/guidelines/modules/ROOT/pages/vpath.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-= Defining source and build directories
-
-Build systems that support defining source/build directories via RPM macros:
-
-* xref:CMake.adoc[CMake]
-* xref:Meson.adoc[Meson]
-
-Macros:
-
-`+%_vpath_srcdir+`::
-  Path (relative to the RPM build directory) where the sources to be built are located (default: `+.+`).
-`+%_vpath_builddir+`::
-  Path (relative to the RPM build directory) where the built objects are located (default: `+%{_target_platform}+`).
diff --git a/guidelines/modules/ROOT/pages/what-can-be-packaged.adoc b/guidelines/modules/ROOT/pages/what-can-be-packaged.adoc
deleted file mode 100644
index 38cca68..0000000
--- a/guidelines/modules/ROOT/pages/what-can-be-packaged.adoc
+++ /dev/null
@@ -1,104 +0,0 @@
-= What can be packaged
-:packaging-committee: https://fedoraproject.org/wiki/Packaging_Committee[Packaging Committee]
-:legal-team: https://fedoraproject.org/wiki/Legal:Main[Legal Team]
-:kernel-team: https://fedoraproject.org/wiki/Kernel[Kernel Team]
-
-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 {packaging-committee} and the {legal-team} are the primary places to receive answers.
-
-== Legal Issues
-
-Some software (or in some cases, portions of that software) cannot be packaged for legal reasons. This includes issues related to licensing, patents, trademark law, etc.
-
-See the following pages for various examples.
-
-* https://fedoraproject.org/wiki/Legal:Main
-* https://fedoraproject.org/wiki/Legal:Licenses
-* https://fedoraproject.org/wiki/Forbidden_items
-
-== Impermissible Content
-
-It is important to make distinction between computer executable code and content.
-While code is permitted (assuming, of course, that it has an open source compatible license, is not legally questionable, etc.), only some kinds of content are permissible.
-
-The rule is this:
-
-If the content enhances the OS user experience, then the content is OK to be packaged in Fedora. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK.
-
-Content still has to be reviewed for inclusion. It must have an open source compatible license, must not be legally questionable. In addition, there are several additional restrictions for content:
-
-* Content must not be pornographic, or contain nudity, whether animated, simulated, or photographed. There are better places on the Internet to get porn.
-* Content should not be offensive, discriminatory, or derogatory. If you're not sure if a piece of content is one of these things, it probably is.
-* All content is subject to review by FESCo, who has the final say on whether or not it can be included.
-
-Some examples of content which is permissible:
-
-* Package documentation or help files.
-* Clipart for use in office suites.
-* Background images (non-offensive, discriminatory, with permission to freely redistribute).
-* Fonts (under an open source license, with no ownership/legal concerns).
-* Game levels are not considered content, since games without levels would be non functional.
-* Sound or graphics included with the source tarball that the program or theme uses (or the documentation uses) are acceptable.
-* Game music or audio content is permissible, as long as the content is freely distributable without restriction, and the format is not patent encumbered.
-* Example files included with the source tarball are not considered content.
-
-Some examples of content which are not permissible:
-
-* Comic book art files
-* Religious texts
-* Files in patent-encumbered media formats
-
-If you are unsure if something is considered approved content, ask the {packaging-committee} or, if your question is of a legal nature, {legal-team}.
-
-== Packages which are not useful without external code
-
-Some software is not functional or useful without the presence of external code dependencies in the runtime operating system environment. When those external code dependencies are non-free, legally unacceptable, or binary-only (with the exception of permissible firmware), then the dependent software is not acceptable for inclusion in Fedora. If the code dependencies are acceptable for Fedora, then they should be packaged and included in Fedora as a pre-requisite for inclusion of the dependent software. Software which downloads code bundles from the internet in order to be functional or useful is not acceptable for inclusion in Fedora (regardless of whether the downloaded code would be acceptable to be packaged in Fedora as a proper dependency).
-
-This also means that packages which are not functional or useful without code or packages from third-party sources are not acceptable for inclusion in Fedora.
-
-== Only one kernel package
-
-Fedora allows only a single kernel package; packages containing alternate kernels are not allowed in the distribution. If there are kernel features which would be generally useful, please communicate with the {kernel-team}.
-
-== No external kernel modules
-
-Fedora does not allow kernel modules to be packaged outside of the main kernel package. You should communicate with the {kernel-team} regarding enabling additional kernel modules.
-
-[#prebuilt-binaries-or-libraries]
-== No inclusion of pre-built binaries or libraries
-
-All program binaries and program libraries included in Fedora packages must be built from the source code that is included in the source package. This is a requirement for the following reasons:
-
-* Security: Pre-packaged program binaries and program libraries not built from the source code could contain parts that are malicious, dangerous, or just broken. Also, these are functionally impossible to patch.
-* Compiler Flags: Pre-packaged program binaries and program libraries not built from the source code were probably not compiled with standard Fedora compiler flags for security and optimization.
-
-Content binaries (such as .pdf, .png, .ps files) are _not_ required to be rebuilt from the source code.
-
-If you are in doubt as to whether something is considered a program binary or a program library, here is some helpful criteria:
-
-* Is it executable? If so, it is probably a program binary.
-* Does it contain a `+.so+`, `+.so.#+`, or `+.so.#.#.#+` extension? If so, it is probably a program library.
-* If in doubt, ask your reviewer. If the reviewer is not sure, they should ask the Fedora Packaging Committee.
-
-Packages which require non-open source components to build are also not permitted (e.g. proprietary compiler required).
-
-When you encounter prebuilt binaries in a package you *MUST*:
-
-* Remove all pre-built program binaries and program libraries in %prep prior to the building of the package. Examples include, but are not limited to, `+*.class+`, `+*.dll+`, `+*.DS_Store+`, `+*.exe+`, `+*.jar+`, `+*.o+`, `+*.pyc+`, `+*.pyo+`, `+*.egg+`, `+*.so+`, `+*.swf+` files.
-* Ask upstream to remove the binaries in their next release.
-
-=== Exceptions
-
-* Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. Please note that this exception, if granted, is limited to only the initial build of the package. You may bootstrap this build with a "bootstrap" pre-built binary, but after this is complete, you must immediately increment Release, drop the "bootstrap" pre-built binary, and build completely from source. Bootstrapped packages containing pre-built "bootstrap" binaries must not be pushed as release packages or updates under any circumstances. These packages should contain the necessary logic to be built once bootstrapping is completed and the prebuilt programs are no longer needed. Information about how you should break circular dependencies by bootstrapping can be found xref:index.adoc#bootstrapping[here].
-* An exception is made for binary firmware, as long as it meets the requirements documented https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware[here].
-* Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. See: xref:SourceURL.adoc#when-upstream-uses-prohibited-code[When Upstream uses Prohibited Code].
-
-[#pregenerated-code]
-== Pregenerated code
-
-Often a package will contain code which was itself generated by other code. This often takes the form of configure files or parsing code generated by bison/yacc or lex/flex.
-
-It is required that the original source files from which the code was generated be included in the source package. Generally these files are part of the source archive supplied by upstream, but it may be necessary to fetch those files from an upstream source repository and include them in the source package as separate Source: entries.
-
-It is preferred, but not required, that the tools used to generate such code be free software and included in Fedora.
-
-It is suggested, but not required, that such code be regenerated as part of the build process. The means for doing this are entirely specific to the individual package being built, but it may happen automatically if the necessary dependencies are present at build time.
diff --git a/site.yml b/site.yml
deleted file mode 100644
index 29aacbd..0000000
--- a/site.yml
+++ /dev/null
@@ -1,21 +0,0 @@
-site:
-  title: Packaging Guidelines (Local Preview)
-  start_page: packaging-guidelines::index.adoc
-content:
-  sources:
-  - url: .
-    branches: HEAD
-    start_path: guidelines
-ui:
-  bundle:
-    url: https://gitlab.com/fedora/docs/docs-website/ui-bundle/-/jobs/artifacts/HEAD/raw/build/ui-bundle.zip?job=bundle-stable
-    snapshot: true
-  default_layout: with_menu
-output:
-  clean: true
-  dir: ./public
-  destinations:
-  - provider: archive
-runtime:
-  fetch: true
-  cache_dir: ./cache

