What is packit
Packit (https://packit.dev/) is a CLI tool that helps you auto-maintain your upstream projects into the Fedora operating system. But what does it really mean?
As a developer, you might want to update your package in Fedora. If you’ve done it in the past, you know it’s no easy task. If you haven’t let me reiterate: it’s no easy task.
And this is exactly where packit can help: once you have your package in Fedora, you can maintain your SPEC file upstream and, with just one additional configuration file, packit will help you update your package in Fedora when you update your source code upstream.
Furthermore, packit can synchronize downstream changes to a SPEC file back into the upstream repository. This could be useful if the SPEC file of your package is changed in Fedora repositories and you would like to synchronize it into your upstream project.
Packit also provides a way to build an SRPM package based on an upstream repository checkout, which can be used for building RPM packages in COPR.
Last but not least, packit provides a status command. This command provides information about upstream and downstream repositories, like pull requests, release and more others.
Packit provides also another two commands: build and create-update.
The command packit build performs a production build of your project in Fedora build system – koji. You can Fedora version you want to build against using an option –dist-git-branch. The command packit create-updates creates a Bodhi update for the specific branch using the option —dist-git-branch.
You can install packit on Fedora using dnf:
sudo dnf install -y packit
For demonstration use case, I have selected the upstream repository of colin (https://github.com/user-cont/colin). Colin is a tool to check generic rules and best-practices for containers, dockerfiles, and container images.
First of all, clone colin git repository:
$ git clone https://github.com/user-cont/colin.git
$ cd colin
Packit expects to run in the root of your git repository.
Packit (https://github.com/packit-service/packit/) needs information about your project, which has to be stored in the upstream repository in the .packit.yaml file (https://github.com/packit-service/packit/blob/master/docs/configuration.md#projects-configuration-file).
See colin’s packit configuration file:
$ cat .packit.yaml
What do the values mean?
- specfile_path – a relative path to a spec file within the upstream repository (mandatory)
- synced_files – a list of relative paths to files in the upstream repo which are meant to be copied to dist-git during an update
- upstream_project_name – name of the upstream repository (e.g. in PyPI); this is used in %prep section
- downstream_package_name – name of the package in Fedora (mandatory)
For more information see the packit configuration documentation (https://github.com/packit-service/packit/blob/master/docs/configuration.md)
What can packit do?
Prerequisite for using packit is that you are in a working directory of a git checkout of your upstream project.
Before running any packit command, you need to do several actions. These actions are mandatory for filing a PR into the upstream or downstream repositories and to have access into the Fedora dist-git repositories.
Export GitHub token taken from https://github.com/settings/tokens:
$ export GITHUB_TOKEN=<YOUR_TOKEN>
Obtain your Kerberos ticket needed for Fedora Account System (FAS) :
$ kinit <yourname>@FEDORAPROJECT.ORG
Export your Pagure API keys taken from https://src.fedoraproject.org/settings#nav-api-tab:
$ export PAGURE_USER_TOKEN=<PAGURE_USER_TOKEN>
Packit also needs a fork token to create a pull request. The token is taken from https://src.fedoraproject.org/fork/YOU/rpms/PACKAGE/settings#apikeys-tab
Do it by running:
$ export PAGURE_FORK_TOKEN=<PAGURE_FORK_TOKEN>
Or store these tokens in the ~/.config/packit.yaml file:
$ cat ~/.config/packit.yaml
Propose a new upstream release in Fedora
The command for this first use case is called propose-update (https://github.com/jpopelka/packit/blob/master/docs/propose_update.md). The command creates a new pull request in Fedora dist-git repository using a selected or the latest upstream release.
$ packit propose-update
INFO: Running 'anitya' versioneer
Version in upstream registries is '0.3.1'.
Version in spec file is '0.3.0'.
WARNING Version in spec file is outdated
Picking version of the latest release from the upstream registry.
Checking out upstream version 0.3.1
Using 'master' dist-git branch
Copying /home/vagrant/colin/colin.spec to /tmp/tmptfwr123c/colin.spec.
Archive colin-0.3.0.tar.gz found in lookaside cache (skipping upload).
INFO: Downloading file from URL https://files.pythonhosted.org/packages/source/c/colin/colin-0.3.0.tar.gz
100%[=============================>] 3.18M eta 00:00:00
Downloaded archive: '/tmp/tmptfwr123c/colin-0.3.0.tar.gz'
About to upload to lookaside cache
won't be doing kinit, no credentials provided
PR created: https://src.fedoraproject.org/rpms/colin/pull-request/14
Once the command finishes, you can see a PR in the Fedora Pagure instance which is based on the latest upstream release. Once you review it, it can be merged.
Sync downstream changes back to the upstream repository
Another use case is to sync downstream changes into the upstream project repository.
The command for this purpose is called sync-from-downstream (https://github.com/jpopelka/packit/blob/master/docs/sync-from-downstream.md). Files synced into the upstream repository are mentioned in the packit.yaml configuration file under the synced_files value.
$ packit sync-from-downstream
upstream active branch master
using "master" dist-git branch
Copying /tmp/tmplvxqtvbb/colin.spec to /home/vagrant/colin/colin.spec.
Creating remote fork-ssh with URL email@example.com:phracek/colin.git.
Pushing to remote fork-ssh using branch master-downstream-sync.
PR created: https://github.com/user-cont/colin/pull/229
As soon as packit finishes, you can see the latest changes taken from the Fedora dist-git repository in the upstream repository. This can be useful, e.g. when Release Engineering performs mass-rebuilds and they update your SPEC file in the Fedora dist-git repository.
Get the status of your upstream project
If you are a developer, you may want to get all the information about the latest releases, tags, pull requests, etc. from the upstream and the downstream repository. Packit provides the status command for this purpose.
$ packit status
ID Title URL
---- -------------------------------- ---------------------------------------------------------
14 Update to upstream release 0.3.1 https://src.fedoraproject.org//rpms/colin/pull-request/14
12 Upstream pr: 226 https://src.fedoraproject.org//rpms/colin/pull-request/12
11 Upstream pr: 226 https://src.fedoraproject.org//rpms/colin/pull-request/11
8 Upstream pr: 226 https://src.fedoraproject.org//rpms/colin/pull-request/8
GitHub upstream releases:
Latest bodhi updates:
Update Karma status
------------------ ------- --------
colin-0.3.1-1.fc29 1 stable
colin-0.3.1-1.fc28 1 stable
colin-0.3.0-2.fc28 0 obsolete
Create an SRPM
The last packit use case is to generate an SRPM package based on a git checkout of your upstream project. The packit command for SRPM generation is srpm.
$ packit srpm
Version in spec file is '0.3.1.37.g00bb80e'.
Packit as a service
In the summer, the people behind packit would like to introduce packit as a service (https://github.com/packit-service/packit-service). In this case, the packit GitHub application will be installed into the upstream repository and packit will perform all the actions automatically, based on the events it receives from GitHub or fedmsg.
IMHO, the title is very misleading and suggesting something that’s not the case…packit doesn’t not “auto-package” a tool. It help to maintain your package in Fedora or the eco-system after you have written a SPEC file and went through the review process.
Thanks for the feedback, Fabian. Even though auto-packaging is the aspiration as I understand it, I agree it doesn’t reflect the current state. I’ve worked with the author on updating the article to make it accurate and just republished it. Sorry about that.
That said, I’m quite interested to see where the project goes in the future — we definitely need more automation! 🙂
This seems to be missing something:
I’d love to package some things I feel are missing in Fedora. I’ve hung around freenode for a bit, but didn’t get much help… Doesn’t seem very easy to get started…
A tool which actually tries to automatically generate a spec file is available in Clear Linux:
It might be inspiration to someone in the Fedora ecosphere.