Development on Fedora Silverblue and Fedora Kinoite
This is a guide covering how to work on applications on Fedora Silverblue and Fedora Kinoite. Depending on the case, it may be easier to work with Flatpak, with RPM packages or directly from the source repository thus I will cover all three options.
Note that while this guide focuses on Fedora Silverblue and Fedora Kinoite, it also applies to all rpm-ostree based Fedora variants and in a lesser form to all distributions that feature Flatpak and toolbox.
As always, make sure to backup your data before attempting system wide changes that could result in the loss of your personal cat picture collection.
If you encounter issues with this guide, reach out to me in one of the following Matrix rooms: Flatpak, KDE Flatpaks, Fedora Silverblue, Fedora KDE.
Try to avoid contacting me privately as there is a high chance that other people from those rooms will also be able to help you with your issue.
If you want to work on building images of Fedora Silverblue, Fedora Kinoite or other desktop variants, you should follow the steps from the README in the workstation-ostree-config repo.
Initial setup
As we will be working on Fedora Silverblue or Fedora Kinoite, we will install all of the needed development tools inside of a toolbx.
All the following commands in this guide will then be executed from this toolbox. Commands that should be executed on the host will be prefixed with [host]
and I will omit the [toolbox]
prefix.
Development using Flatpak
This method is particularly usefull if the application is already packaged as a Flatpak or if it is a good fit for Flatpak. With this method, you can directly work on the source code, re-build the application and see the result.
For this example, we will use Kcalc.
Install tools to build Flatpaks
Enter your toolbx as explained above and install flatpak-builder
with:
Get the source
Clone the application sources from the upstream repo and optionaly checkout the branch you want to work on:
Create or copy a Flatpak manifest
Kcalc is already published on Flathub thus we can get the Flatpak manifest from there:
You can find a lot of applications on Flathub or in the KDE Flatpak repo for nightly builds.
If your application does not already have a manifest, consider making one and submitting it to FlatHub. See the Flatpak documentation and the FlatHub submission guide.
Build the application source using Flatpak
Copy the Flatpak manifest into the application source folder:
Tweak the manifest to directly use the sources from the Git repository:
1
2
3
4
5
6
7
8
9
10
11
12
13
...
{
"name": "kcalc",
"buildsystem": "cmake-ninja",
"config-opts": ["-DINSTALL_ICONS=ON"],
"sources": [
{
"type": "dir",
"path": "./"
}
]
}
...
Add the Flathub remote to get access to all SDK, Runtimes and extensions from there:
Install the SDK needed to build the application (see the top of the manifest):
Note: The //
is intentional here. You can skip the version specification and Flatpak will ask you which version to use.
Build the application with Flatpak:
Test the resulting Flatpak
You can then test your application with:
Sometimes you will have to install the application to get special permissions to work:
Restore the original version
You may uninstall the Flatpak with:
Development using RPM packages
This method is particularly usefull if you are working on the kernel or an application that is involved in the boot process and thus requires a reboot for testing.
For this example, we will use systemd.
Install tools to build RPMs
Enter your toolbx as explained at the beginning and install fedpkg
with:
Get the RPM spec file
Clone the repository with the sources needed to build the RPM package and switch to the branch for the release you are working on:
Get the source
Clone the application sources from the upstream repo and checkout the release tag corresponding to the release you are working on:
Create a patch and use it in the spec file
Make the change that you need in the sources and create a patch:
Edit the spec file to add the patch:
Rebuild the RPM locally
Install the build dependencies:
Then we can rebuild the package locally:
You should now have RPM packages in a subfolder ./x86_64/systemd-*.rpm
.
Install the RPM on the host
We can now install the RPM with rpm-ostree:
But in this case as the package you want to install is already available in the host, you will have to override it:
Test the change
We can then reboot to test the new deployment with the replaced package.
If we want the changes to apply directly on the running system without a reboot, we can also use --apply-live
:
or for overrides (still experimental, command line subject to change):
This will also be preserved if we reboot.
Restore the default state
You can remove your package with:
or reset your override with:
and then reboot.
Development from the source repository
This method is particularly useful when it does not make sense to package your application as a Flatpak (for example because it is part of the base image already) or if you need to have full control over the build process, configuration flags, etc. without having to extensively modify the RPM spec file.
For this example we will use Discover.
Get the source
Clone the application sources from the upstream repo and optionaly checkout the branch you want to work on:
Install build dependencies
Install the build dependencies using dnf (using the name as packaged on Fedora):
If your application is not yet packaged, you will have to figure out the dependencies and install them manually.
Configure and build the application
Use either upstream instructions, configuration options or re-use the ones from the RPM package (if available). For example:
Install to a temporary folder
To make sure that we will not negatively impact our running system, we will install the application in a temporary folder and then sync to our live system only the parts strictly needed:
Unlock your local deployment
We then use rpm-ostree
to create an ephemeral (lost on reboot) and writable overlay on top of /usr
:
Note that we run that command on the host.
Sync to your local deploypment
Finally we can use rsync
to install our application to our running system:
Note that we run that command on the host.
Test
We can now test our application as if it had always been part of the OS image:
Note that we run that command on the host.
Restore the default state
The simplest option is to reboot. You will get back to the latest deployment available without any local changes.
Conclusion
Those steps might feel unfamiliar to those used to development on classic Linux distributions. However, development on Fedora Silverblue and Fedora Kinoite is made safer by the use of Flatpak and rpm-ostree, without sacrifying speed. Both projects make it easy to try changes while making sure that you can always go back to a working state should anything unexpected happen.
Comments
You can also contact me directly if you have feedback.