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 was not released when I prepared the pictures for this post. Since it took me far to 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 like 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!
Installing the system
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 last 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 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” partitions to subdivide a drive further.
If you’re new to OpenBSD you may be astounded when you see how many disklabels 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 / disklabel this would not have been possible. Of course there’s more to the decision for each default disklabel but you get the idea.
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 tarballs 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.
While OpenBSD provides cdXX and installXX isos for each release, there’s only one type available for the snapshots. It is equivalent to cdXX which does not contain the installation sets. For that reason they have to be downloaded from the net before they can be installed.
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.
Back to Pac!
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:
- wget (to fetch the Pacman source)
- bash (because Pacman needs it)
- libarchive (used by Pacman)
- gcc 4.9 (because OpenBSD’s old system compiler (4.2!) won’t build Pacman)
- gmake (Pacman requires it to build)
After the source has been unpacked it’s time to configure it.
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.
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, we need to skip the checks, too.
Then 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.
Next try! Makepkg unpacks the source, runs configure and – fails. Ok, 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.
After fakeroot is present 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 complaining. The reason is that GNU install uses some extensions unknown and thus unavailable on *BSD systems. Now we’re really close!
The solution in this case is to modify the PKGBUILD file again, remove the offending parameter and create directories with mkdir. Next attempt!
Success! The first Pacman package for OpenBSD was built!
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.
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.
Pacman on OpenBSD – why?
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. Point 1: A fully managed system is cleaner.
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 contrary 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!). Point 2: Packaging via shell scripting is easier to write, read and learn.
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. Point 3: It would make updating the system easier and more consistent (why should the core OS be treated differently from the application programs?).
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 line. 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 from the average Linux user.