Skip to content

Rebasing a Package on Fedora

Jump to bottom
Marco Fargetta edited this page Nov 6, 2023 · 16 revisions

Overview

This page describes the process for rebasing (as opposed to patching) a package on Fedora.

As an example, we’ll try to rebase the dogtag-pki package on Fedora 35 to upstream PKI 11.0.0-beta1.

Prerequisites

First, gather the following information from Fedora Packages (i.e. Fedora 35 Packages) page:

  • Upstream project repository and branch/tag (i.e. pki/master)

  • Package dist-git repository and branch (i.e. dogtag-pki/f35)

Authorization

Make sure you have the authorization to update the upstream project repository (if necessary) and the dist-git repository, for example:

$ kinit <username>@FEDORAPROJECT.ORG

Getting the Sources

Next, clone the above repositories into the local machine:

You can reuse existing repositories on your local machine if they are already checked out. It’s not necessary to clone new ones every time.

Updating Upstream Version Number

Check the commit history in the upstream project branch. If the latest commit has been tagged, there is nothing to change upstream. If it has not been tagged, find the latest tag in the branch, then make sure the branch has a newer version number than the latest tag, then create a new tag with the new version number.

In the local upstream project repository check out the upstream branch/tag (i.e. master):

$ git checkout master
$ git pull

Suppose the latest tag in the branch is v11.0.0-alpha1, the version number should be updated to 11.0.0-alpha2 or 11.0.0-beta1 or 11.0.0 depending on the development stage.

To change the version number, edit the following fields in pki.spec:

Version:          11.0.0
Release:          0.4.beta1%{?_timestamp}%{?_commit_id}%{?dist}
%global           _phase -beta1

Commit the changes upstream:

$ git commit -a -m "Update version number to 11.0.0-beta1"
$ git push origin master

Then create a tag with the new version number:

$ git tag v11.0.0-beta1

Notes:

  • Do not include the release number since this is an upstream tag.

  • Do not push the tag to origin just yet in case it needs to be redone.

Creating a Source Tarball

Create a source tarball with the new tag:

$ ./build.sh --source-tag=v11.0.0-beta1 src

In this case the source tarball will be stored in pki-11.0.0-beta1.tar.gz.

Adding the Source Tarball

In the local dist-git repository check out the dist-git branch (i.e. f35):

$ git checkout f35
$ git pull

Import the tarball into dist-git with this command:

$ fedpkg new-sources <path to>/pki-11.0.0-beta1.tar.gz

Merge the Spec Files

Next, merge the upstream spec file into the dist-git spec file.

Use a merging tool such as meld to merge the files, for example:

$ meld <upstream>/pki.spec <dist-git>/dogtag-pki.spec

In general most changes in upstream spec file should be merged into dist-git spec file, and most changes in dist-git spec file should be removed. If there are dist-git changes that cannot be removed, try to merge and commit it upstream if possible. Ideally the files should become identical except for platform specific macros, patch files, and change logs.

Remove Unused Patch Files

Next, remove any patch files that are already included in the upstream branch from dist-git spec file:

Patch1: <filename>

Also remove the patch files from dist-git:

$ git rm <filename>

Adding a Change Log

Add a change log entry to describe the changes.

Find the following line in the spec file:

%changelog

Add the new entry (newest log at the top), for example:

* Fri Sep 03 2021 Dogtag PKI Team <[email protected]> - 11.0.0-0.4.beta1
- Rebase to PKI 11.0.0-beta1

Testing Dist-Git Changes

The following steps can optionally be executed to verify the changes before starting the official build.

Verify that the source tarball and the patches (if any) are valid:

$ fedpkg prep

Verify that the spec changes are valid:

$ fedpkg lint

Create an SRPM file, then create a scratch build:

$ fedpkg srpm
$ fedpkg scratch-build --srpm <SRPM file>

Committing Dist-Git Changes

Commit the changes to dist-git repository with the following commands:

$ git add dogtag-pki.spec
$ git commit

Enter a short (i.e. one line) summary:

Rebase to PKI 11.0.0-beta1

Pushing Dist-Git Changes

Push the changes to dist-git repository:

$ git push origin f35

Creating the Build

Before creating the build, create a side tag (this is required to build multiple packages):

$ fedpkg request-side-tag
Side tag 'f40-build-side-77104' (id 77104) created.
$ koji wait-repo f40-build-side-77104

Then start the build with the following command:

$ fedpkg build --target=f40-build-side-77104

If there’s a problem with the build, fix it in the upstream branch and start over, or add a patch.

Pushing Upstream Tag

If everything went well, push the upstream tag to origin:

$ git push origin v11.0.0-beta1

Creating Bodhi Update

Finally, create a Bodhi update which includes the new build and the dependencies (if any). For example, to create a Bodhi update from command-line:

$ bodhi updates new \
   --request=testing \
   --type=enhancement \
   --notes="Update to PKI 11.0.0-0.4.beta1" \
dogtag-pki-11.0.0-0.4.beta1.fc35 \
jss-5.0.0-0.4.beta1.fc35

The builds then will be added into Fedora updates testing repository. Once the update receives enough Karma points, the builds will be released into Fedora stable repository.

Note: The Bodhi update is not required for Rawhide in case of a single pacakge but it is required if a side-tag is used.

See Also

Tip
 To find a page in the Wiki, enter the keywords in search field, press Enter, then click Wikis.
Clone this wiki locally