Congratulation!
Now you have your really own remote and local repository, we can start the real business!
Git is a version control system, so it can store your stuff with versions and stuff. Look for it on github or somewhere else, i won’t go too deep, only so far, what needed to your adventure.
A github repository, like your local can have a remote pair. In this case your remote repository is your own github haikuports repo. Everything was set up automatically as you cloned your repo.
Your local git repo have a default branch it called “master”. This is the most important branch, you can think about it like a holy cow. Do not mess with your “master”. Never ever.
Now, navigate into your repository in terminal like:
cd /boot/home/haikuports
If you wan’t make any changes in the repo, first check, which branch is active, and what the status like:
git status
It will print you, that you are on master and your repository is clean. Good.
As i told you, you do not want to mess with your master, but you have to base all your changes onto your master. It called branching. If you make a branch from master, it will be a separate sandbox where you can do everything, and everything will be based on top of your master,but you don’t actually change your master.
Let suppose, you want to work on the scribus ecipe, let’s do a branch for it:
git checkout -b scribus_update
Git will create a branch for you called “scribus_update”, and change to it automatically. You can check it wit the good ol’:
git status
It will report, that you are on the “scribus_update” branch, and your repository is clean.
Good work, mate!
So, let’s see, what we have done:
- we made a fork about the official haikuports repo (this is your remote repo at github)
- you just cloned your remote repo. (this is your local repo)
- you just made a branch in your local repo, where you can do everything.
Now, as you told, you want to work on the scribus recipe, let’s navigate with Tracker into the scribus folder (it is in app-office/scribus).
Here you can see 2 recipe and some folders.
We have a 1.4.6 and a 1.5.2 recipe. You wan’t to update the scribus port to the latest one, so take the 1.5.2 recipe and duplicate it in Tracker. Then rename it to 1.5.3.
Do not forget to remove a “copy” postfix from the file-name.
Great! Nice job!
The point is, that haikuporter takes the version number from the file-name, and uses it in plenty different places, so a correct recipe defines its version only one times: in the file-name.
We took an old recipe, and renamed it, so haikuporter will know, it is a new version.
Let’s open the recipe with Pe. Do not change anything, just look at the different sections and try to analyze, how it built up, what kind of informations contains. Maybe there will be some unknown stuff, or some stuff, what you cannot decipher, but do not panic, first you need to look at it a bit, to get a bit intim connection with it.
The first some line is really straightforward to decipher, but at the SOURCE_URI you will see an web address (URL) what contains the following string:
$portVersion
Maybe you remember, haikuporter takes the version number from the file name, and reuses it plenty times. $portVersion is actually the version number. It will be replaced with the actual version number during the build, so you can think like a placeholder for “1.5.3”
The CHECKSUM_SHA256 is a CRC check stuff. Do not care about it right now. It is to check the integrity of the downloaded source code. We will talk about it later.
PATCHES is a really important stuff. Sometimes the source codes needs some changes to get it compiled on Haiku. If we need any patch, we will list it here.
As you can see, there is already a patch defined with $portVersion in it’s name. IT means, haikuporter needs to look in the “patches” folder for a file called “scribus-$portVersion.patchset” (the current recipe version.
ARCHITECTURES means: which processor architectures are supported. It isn’t actually a processor architecture, but the Haiku version. As you can see, there is more than one defined.
Let’s see them:
!x86_gcc2 means: it isn’t works on gcc2h PRIMARY arch.
?x86 means: it isn’t tested on x86 primary arch
?x86_64 : means it isn’t tested on x86_64 primary arch.
What is this primary arch stuff actually?
Haiku, historycally source and binary compatible with BeOS. BeOS had GCC2 compiler toolchain, so the traditional Haiku (gcc2h) comes with GCC2 what a bit old, and doesn’t support the shiny new features. The Haiku dev team solved this with the primary and secondary arch:
- Haiku gcc2h comes with 2 different GCC compiler toolchain, the primary is gcc2 and the secondary is gcc5.
- There is a Haiku version with opposite toolchains too: gcc5 as primary and gcc2 as secondary. This is the second in this line.
- There is a x86_64 Haiku version too. It comes only with one GCC: gcc5, so the primary here is gcc5.
Now you understand the SECONDARY_ARCHITECTURES too.
Thencomes the PROVIDES section: here can we define, what does this package provides.
REQUIRES contains the runtime dependencies. Theese the packages what the end-user need, who do not want build it, just use it the resulting package.
PROVIDES_devel: is special stuff. Maybe you have noticed, some package have a _devel pair. This is the developer stuff, what not everybody needs. The libraries are mostly splitted up to “runtime” and “developer” stuff. The normal users needs the runtime stuff, the developers (like you) needs the developer packages TOO.
The PROVIDES_devel section means: scribus will be split up to runtime and developer package, and we defined here, what the developer package contains.
REQUIRES_devel: means what the scribus_devel package needs.
BUILD_REQUIRES: contains all the libraries, what haikuporter needs to build this package
BUILD_PREREQUIRES: contains all the programs, what required to build the package
BUILD() section will build the program
INSTALL() will install it
We already bumped the file name to 1.5.3, but our recipe contains a PATCHES section, where the portVersion variable used. We don’t have a patch like “scribus-1.5.3.patchset”. We got just 1.5.2 in the patches folder.
If i update a port, i always check if the old patchset still works or not. We can copy the old patchset and rename it to 1.5.3, but we have luck, @korli already sent theese patches to the scribus folks, and they are integrated into the current (1.5.3) version, so we don’t need the PATCHES section. LEt’s comment it out like:
#PATCHES="scribus-$portVersion.patchset"
Add a hashmark to the beginning. like in my example and save the file.
Now you got a preliminary recipe what we can try, so go to your Terminal, and let haikuporter bo the stuff:
haikuporter scribus
on x86_64, or
haikuporter scribus_x86
on haiku gcc2h.
If you start it, haikuporter will check the repository (i assume, your haikuporter already configured correctly, if not, check the haikuporter wiki) and finds your current scribus recipe. It will download the current sources and prints an error message, that the Checksum doesn’t match. Of course it isn’t, because it is a checksum of the 1.5.2 version, but we want 1.5.3. Haikuporter kind enough to show you the actual checksum, so copy it and paste it into your recipe. Replace the old checksum with the new one and try to build it again with the :
haikuporter scribus
command. Look! It went further!
It will complain later because something else, but i let you experience it alone.
Report back if you accomplished theese steps and i’ll guide you further.
Have fun!
