Here I'm republishing an old blog post of mine originally from May 2015. The article has been slightly improved.
Background: This article relies on screenshots quite heavily and thus is not particularly Gemini friendly. But as it's an old post migrated over, I chose to not change it completely - so this is a flaw we'll have to live with.
A bit belated comes the second part of "installing Pacman on OpenBSD". The previous post was about the attempt to get Pacman up and running on OpenBSD 5.6. In the end it failed because the OS did not know about the 'blkcnt_t' type. This was nothing that a non-programmer could fix easily - but fortunately this new type is available in the upcoming OpenBSD 5.7. So we're going to continue with that.
OpenBSD 5.7 had not been released when I prepared the pictures for this post. Since it took me far too long to complete this article, it was released yesterday. Anyways: OpenBSD comes in three "flavors": _Release_, _Stable_ and _Current_. Releases (like 5.7) are made twice a year and stay as they are. If any problems with OpenBSD are found, patches are made available. The patched code resides in the _stable branch_ which you should track to keep a secure and up to date system.
And then there's _current_. This branch contains the latest code. It's meant for developers, testers and all kind of people who like to live on the edge or who want/need the latest features. You can update a release or stable system to current, but especially in case of bigger changes it's best to start with a snapshot - and we'll do just that in a minute.
So far I hadn't been looking into OpenBSD deep enough to use anything else than release/stable. Time for my first peek at current and thus the upcoming 5.7 release!
Setting up a new system, we're meeting the installer again. I didn't notice too many differences from 5.6, so I'll just show some screenshots from different parts of it.
One thing that I didn't show in the previous post was the creation of the disklabels. If you want to work with *BSD you should get an idea of what this is before thinking about how to partition your drive(s). In short: While the PC's MBR allows for 4 primary partitions (a limit which was overcome with the extended partitions later), the systems Unix originally ran on didn't provide such a facility. To be able to partition disks on those machines, disklabels were invented. On a PC you may think of them as "sub-partitions" since they are created inside "real" MBR partitions to further subdivide a drive.
If you're new to OpenBSD, you may be astounded when you see how many disklabel partitions OpenBSD creates by default. This is in fact a security feature. OpenBSD mounts /tmp with _noexec_ for example which means that if an attacker manages to place a binary there, it's not going to be of much use since no program can be executed on this partition. If /tmp had been part of the / partition, this would not have been possible. Of course there's more to the decision for each default disklabel partition but you get the idea.
Creating disklabel partitions with the installer (PNG)
Now if you look closely, you can see one difference between 5.6 and 5.7: There are fewer sets to choose from! This is due to the fact that _etcXX_ and _xetcXX_ are no longer separate sets but have been moved into _baseXX_ and _xbaseXX_ respectively.
While this is something that OpenBSD veterans will have to mind when updating, for us beginners it is not too exciting a change. And when doing a fresh installation it totally makes sense to have the etc set installed as part of base, anyway.
The etcXX and xetcXX sets were merged into the base sets and are no longer available
While OpenBSD provides _cdXX_ (without sets) and _installXX_ (including sets on the media) isos for each release, there's only the former type available for the snapshots. For that reason they have to be downloaded from the net before they can be installed.
Installation from snapshot sets complete! (PNG)
Once the installation process is completed, we can boot into the new system. Upon login the system identifies itself as "OpenBSD 5.7-current" - so we're there and can resume the work on getting Pacman to run on this system.
My first OpenBSD of the "current" flavor!
Alright. From the previous attempt we know that Pacman needs a few things installed so we can build it. This time we just have a slight inconvenience: Using a snapshot there are no pre-built packages available. So that means it's necessary to build each and every package using the ports system. Especially in case of the compiler this takes quite a bit of time.
I'll skip over the details here; what I did was to build and install:
After the source has been unpacked, it's time to configure it.
All dependencies built. On with Pacman! (PNG)
Just like last time, configure is satisfied with the system. But unlike last time, Pacman can actually be built now! So let's go ahead and install it.
Now that it's installed, it's time to try and see if it actually works or if it's going to segfault or anything. Fortunately it only throws an error because I didn't provide any parameter. This is its expected behavior, so everything is fine so far.
Of course there are no packages available for OpenBSD which are compatible with Pacman. So we'll have to create one ourselves. I've installed _links_ via the ports for a little convenience so browsing the Arch Linux pages and getting the first _PKGBUILD_ file is a simple thing.
Getting the first PKGBUILD file with links (PNG)
What next? With the PKGBUILD file for it we should be able to build and package _curl_ shouldn't we? Of course we have to tell _makepkg_ to disregard the package's dependencies because there are no packages installed using Pacman on this system, yet. And since there's also no _gnupg_ available either, we need to skip the checks, too.
With that makepkg is happy. Well, almost. It relies on curl to fetch source tarballs - and since we're attempting to build curl in the first place this obviously won't work. So in this case the best solution is to just wget the source and put it into the working directory.
Pacman needs curl to download sources - let's just wget curl's source (PNG)
Next try! Makepkg unpacks the source, runs configure and - fails. All right, the PKGBUILD file was created for Arch Linux and Linux systems only use _GNU make_ by default and thus simply name it "make". We'll have to edit the file and replace "make" with "gmake".
Much better: Curl is built successfully! However makepkg cannot package it because the _fakeroot_ program is not available on our system. So the next step is to build and install that before trying again.
Curl built, but fakeroot is missing (PNG)
After fakeroot was installed on the system, makepkg is happy again and tries to package curl for us. But we're in for another error message: This time it's _install_ that's complaining. The reason is that _GNU install_ uses some extensions unknown and thus unavailable on *BSD systems. But we're really close!
The solution I chose in this case is to modify the PKGBUILD file again, remove the offending parameter and create directories with mkdir. Next attempt!
Incompatible versions of BSD and GNU install (PNG)
Success! The first Pacman package for OpenBSD was built!
Yay, first package built! 🙂 (PNG)
Now let's install the newly built package and see if that works, too. Does it? Sure thing. And even if that's a pretty short list of installed packages right now, the important first step has been made.
So let's build another package and see if Pacman can make use of the now installed curl. I chose bash because that's one more dependency of the package manager. And really: Everything is fine.
Pacman can now fetch the source itself (PNG)
All done: The second package has been built. Now we could go on and build any other package. In that case we'd come across a lot of problems getting them to build on OpenBSD. That's for sure. But that is general packaging trouble. The goal to bring the Pacman package manager to OpenBSD has been successfully reached.
Second package (bash) built (PNG)
OpenBSD features a package system that is both simple and tried. It does the job. But in some regards a more modern solution could do the job - well, better.
From the Linux perspective it is completely incomprehensible that only the programs which you install on top of the OS are packaged. The operating system itself is installed by unpacking tarballs. There is no package management keeping track of their files. This is the reason why some files have to be deleted by hand on every update. If the OS was managed by a tool like Pacman this would be unnecessary.
The ports are a facility that works. But writing makefiles for everything is a rather tedious task, especially since make requires some black magic now and then to achieve special things. Pacman on the other hand uses _shell scripting_ which is both powerful and easy to read. And I'd claim that it's also far easier to learn than make for people who are not programmers (and package maintainers do not need to be programmers after all!).
Updating the OS itself is a special thing without a real need for this. If the system was managed, updating without booting a ramdisk to unpack tarballs would be possible.
There are more points in favor of a more modern package management solution but most of them are arguably a matter of taste.
Of course there are a few disadvantages of using Pacman as well. For one it's not meant to be used for huge packages like the base system. It works well, but the possibility to patch the base system from one version to the next using deltas for all the files instead of removing the old package and replacing the whole thing with the new one, would be even better.
Another issue is the license: The BSDs prefer permissively licensed applications over "Copy left" models. And Pacman is GPL'ed software.
Nevertheless the combination of OpenBSD + Pacman is an interesting one in my opinion. If anybody else thinks the same - feel free to drop me a comment here.
I've got yet another BSD topic in the pipe. Since I was asked by some friends about FreeBSD, I figured that it would be a good idea to write a little tutorial / introduction to FreeBSD from the perspective of the average Linux user.
