TigerOS RPM Packaging Instructions

RPM Documentation

The documentation on how our Builder creates the RPM packages is found here.

There are two different ways to build an RPM package locally, without using our Builder.

Specfile sources are not local and are pulled from a website.
All sources are local within the directory.

In order to build option 1, you simply need to run fedpkg --release f28 local, replacing 28 with the current Fedora version you wish to build for.

To build option 2, you first need to follow these steps:

Create a directory within the repository titled <package-name>-<%Version>. An example of this would be tigeros-ui-tweaks-1.0/
Add all sources and license into this directory
Tar the directory with tar zcvf <name>-<version>-<release>.fc<fedora version>.tar.gz. Example: tar zcvf tigeros-ui-tweaks-1.0-1.fc28.tar.gz
Run fedpkg --release f28 local, replacing 28 with the Fedora version of choice.

The RPM and source RPM will then be created, with the RPM being within the noarch/ directory.

All TigerOS packages MUST be signed before they can be used on the mirror. Instructions on generating a GPG key for signing packages can be found here.

Packaging Guidelines

In general, TigerOS packages should follow the guidelines at https://fedoraproject.org/wiki/Packaging:Guidelines with the following additions:

TigerOS MUST NOT redistribute software that was originally under a license that does not permit redistribution.
TigerOS MUST NOT relicense said software to permit redistribution.
All code contributed to TigerOS MUST be under a FOSS license and compatible with the licenses of the other parts of the system.
TigerOS RPM packages and specfiles should follow the same structure and directory layout, if possible.

Special notes for creating a TigerOS package

Packages that do not replace upstream Fedora version should install into /usr/local/bin or an appropriate directory in accordance with the FHS.
Packages that do replace the upstream Fedora version should include a conflicts and an obsoletes statement for the Fedora package it replaces. All packages that replace upstream versions should be tested to ensure compatibility.