Linux Kamarada
openSUSE Leap 15.6 was released in June, while Linux Kamarada is at 15.5, released in May. As I’m developing the distribution’s next release, I’m writing this “Linux Kamarada making of” series, in which I try to share how this development is done. So far, this series has two articles already:
- How to make an openSUSE-based distro (Linux Kamarada making of): getting started
- Building RPM packages with the Open Build Service (OBS)
If you haven’t read the previous articles yet, I recommend you start with them.
In the first article, we saw how to start developing an openSUSE-based distribution by creating the repository on the Open Build Service (OBS) and creating the first package by integrating OBS with GitLab. In the second article, we saw how to create a package using just OBS, without using GitLab.
Note that in both articles I started the development of the packages from scratch, to show how it is done. But since I have a previous release (Linux Kamarada 15.5) already built, I can reuse much of my previous work for the next release (Linux Kamarada 15.6), I don’t need to start all over again from scratch.
On OBS, we can do this by creating branches of the packages.
If you’re already used to Git, this word will probably sound familiar to you. But the OBS concept of branch is actually analogous to the Git concept of fork.
Typically, in OBS (as in Git) we use branches (or forks) to contribute to other projects: we access a package (repository), create a branch ( fork) of it in our own space, make changes, and push these changes back to the original package (repository).
To start a new version of a package in a new repository, we’ll make a creative use of OBS branches. Without further ado, let’s get started.
Creating branches on OBS
In the first article, we saw how to create the patterns-kamarada-gnome package from scratch. Today, we’re going to do something different: we’re going to branch the branding-kamarada package into the Linux Kamarada 15.6 project, so that we can reuse the previous work.
Begin by accessing the package in the previous release’s project (in my case, the branding-kamarada package in the home:kamarada:15.5:dev project) and, in the action bar by the left, click Branch Package:
Expand More options and enter the project name (home:kamarada:15.6:dev) and the package name (branding-kamarada) for the branch:
Check the Stay on this revision option so that OBS won’t update the branch if there are updates to the original package.
Also check the Disable Autocleanup option so that OBS won’t delete the branch if it goes a while without receiving changes.
Finally, click the Branch button.
The branding-kamarada package is created in the home:kamarada:15.6:dev project.
Edit the _service file and update the revision parameter:
Note how you can edit this file from the OBS web interface. If you don’t remember what this file is for, take a look at one of the following tutorials:
Unlinking the original package
As I said, we’re making a creative use of OBS branches to take advantage of our previous work on previous versions of the packages. We don’t want to contribute changes back to the original package, nor receive updates from it. So we’re going to unlink the branch from the original package, making the new package independent.
Go back to the project page (the one that lists the packages) and notice that branched packages are tagged with Link:
Click the package in question and note that its page also shows that it is a branch (Links to):
Click show unmerged sources to show only the branch code, without mixing it with the original package code.
This brings up the _link file, which stores the link to the original package:
Delete this file and notice that the link indication disappears both on the package page:
And on the project page:
Finishing
Finish configuring OBS integration with GitLab or GitHub.
And remember to also update the spec and changes files.
Once this is done, you are ready to work on the next version of this package.
Now repeat this procedure for all other packages that you intend to update from one distribution release to the next.
