Rebasing a Package on Fedora - dogtagpki/pki GitHub Wiki
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.
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)
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
Next, clone the above repositories into the local machine:
-
Upstream project repository (i.e.
git clone https://github.com/dogtagpki/pki.git
) -
Package dist-git repository (i.e.
fedpkg clone dogtag-pki Fedora/dogtag-pki
)
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.
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.
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
.
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
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.
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>
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
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>
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
Push the changes to dist-git repository:
$ git push origin f35
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.
If everything went well, push the upstream tag to origin:
$ git push origin v11.0.0-beta1
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.