Skip to main content

Patches

This document describes openRuyi's patch policy.

General Policy

A comment line should precede every patch that a spec file references. This comment may briefly describe the purpose of the patch, or provide a link to the corresponding upstream discussion or source.

Patch File Naming Policy

All patch files should begin with a four-digit numeric prefix. openRuyi reserves different numeric ranges for different types of patches:

  • Use the range 0001-0999 for patches you take from upstream for the same version.

  • Use the range 1000-1999 for CVE fixes and backported patches from other upstream versions.

  • Use the range 2000-2999 for openRuyi-specific patches that do not target upstream acceptance.

Using Individual Patch Tags

Place Patch tags above the BuildOption tag (if present), or above the BuildRequires tag.

# https://github.com/pypa/wheel/pull/655
Patch0: 0001-adjusts-tests-for-setuptools-78.patch

If you prefer, you may also include an explanatory comment together with the link:

# Upstream has removed this code entirely instead
# https://github.com/pypa/wheel/pull/655
Patch0: 0001-adjusts-tests-for-setuptools-78.patch

Using %patchlist

openRuyi does not recommend using individual Patch tags if a package contains more than three patches. In such cases, use %patchlist instead.

When using %patchlist, you must place the patch list above %description. See this discussion for details.

%patchlist
# Fix executable space protection patch, upstream plans to do this
0001-unzip-6.0-exec-shield.patch
# http://www.info-zip.org/board/board.pl?m-1259575993/
0002-unzip-6.0-attribs-overflow.patch
# ...
# covscan issues
0020-unzip-6.0-COVSCAN-fix-unterminated-string.patch

Applying Patches

In the build system of openRuyi, it is generally unnecessary to apply patches manually. The build system will automatically apply patches during the prep stage.

By default, the patch strip level is set to -p1, which is typically suitable for patches generated by git format-patch. These patches usually contain a/ and b/ path prefixes.

You should only use BuildOption(prep) to pass additional arguments when the default preparation stage does not meet your requirements. For example, if the patch paths already start with relative paths from the source root directory, you should explicitly use -p0:

BuildOption(prep):  -p0

You should only write out the %prep section and manually apply patches if the patches require special handling that cannot be expressed through declarative fields. In such cases, you must add a comment in the spec file explaining the reason.