Pacman on OpenBSD (pt. 2)

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.

Snapshot time

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.

Creating disklabels with the installer

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.

The etcXX and xetcXX tarballs were removed

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.

Installation of the snapshot packages complete!

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!

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.

All dependencies built. On with Pacman!

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.

Compilation looks good

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.

Pacman is working!

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

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.

Pacman needs curl to download sources – let’s just wget curl’s source

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.

Curl built, but fakeroot is missing

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!

Incompatible versions of BSD and GNU install

Success! The first Pacman package for OpenBSD was built!

Yay, first package 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.

Confirmed: Pacman works

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

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

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.

What’s next?

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.

Pacman on OpenBSD (pt. 1)

It’s April fool’s time! You knew it: There is no ArchBSD/Open in the making (or at least I don’t know about it). But this year’s April fool actually has some real background – both on the technical and the social side.

Why?

Well, I had the basic idea for this fool since about the beginning of the year. I wanted to bring ArchBSD to the attention of my readers again since I really like the idea. But there was not too much news about the project. So I had to come up with something. And I thought that the humorous aspect of an April fool was just about the right thing.

There was another reason, however, and a rather strange one actually. A while ago I read somewhere that somebody was to leave Arch Linux (for various and IMO very valid reasons) and use OpenBSD instead. Right in the next post he was told in a condescending tone to enjoy the visit because he’d be back in no time anyways. I immediately hated that arrogance! Having been a visitor to *BSD land myself (and having liked quite some things there), the idea was born if there could be an Arch-OpenBSD blend like there was already ArchBSD for FreeBSD.

Just a joke logo

Behavior and sensivities

There’s a lot of bad behavior in the Linux world. On the forums of the now dead distribution CrunchBang I once read that there were also some Archers “creeping around” (there’s another distro, ArchBang, which follows the same design ideas but is based on Arch Linux). Obviously the poster didn’t have much respect for some of his fellow Linux users because another distribution fits their purpose best.

Another member’s signature made it quite clear why: UDOD (“Use Debian or die!”). I have no problem with such signatures or statements. In fact I think they are funny to some degree. The only problem here is: You never know if people are actually serious and do mean it.

Or have you ever witnessed what happens on the Arch forums if somebody admits to be using Manjaro or any other Arch-based distro? Quite often the reactions are… not exactly friendly. Use a different (even a closely related) distribution and you’ll probably make no friends.

Ironically, a somewhat similar thing can happen to you the other way around, too. Just go to the Gentoo forums and dare to ask a beginner’s question. Chances are that you are told how Gentoo is not for you and you should find another distro.

You really have to grow a thick skin in some cases! Fortunately there are also a lot of friendly and very helpful people around. And on the other side there’s this new trend to replace pronouns with “gender-neutral” ones… This takes every day’s imbecility to a whole new level where endless discussions arise not over technical matters but over real or imaginary sensitivities of some minority.

Pacman on OpenBSD?

But enough of that. The net is the net and people are… what people are. Anyways: I begun to wonder if pacman could be installed on OpenBSD, too. And since I actually I liked the idea, I decided to give it a try.

I don’t have too much experience with OpenBSD, yet, but I’ve been following the releases for about two years now and in fact I think it’s a great OS. So let’s install it first! Just like other free operating systems you can download in ISO image for the installation. There’s just one thing wrong with it: The name! No, it’s not a joke this time; the file is just named ‘cd56.iso’. Now I’m all for short names but it should at least be informative. And ‘cd56.iso’ clearly isn’t.

I’ve hated that with Gentoo: They offer images by the name of ‘install-x86-minimal-20150407.iso’ and the likes. Ok, by now I know that this is a Gentoo image but would it really hurt to state just that somewhere? And with OpenBSD it’s even worse: You cannot even tell whether this file is an ISO of a 32-bit or of a 64-bit system! That’s pretty bad. Now if you have both older and newer computers to deal with and download both, you’ll end up with something like ‘cd56 (1).iso’ which is just ugly. And to tell which file is which version, you have to take a look at the size as the 64-bit one is slightly bigger (or you have to remember which one you downloaded first).

Installing OpenBSD

OpenBSD comes with a simple text-mode installer. Simple in this case means that it’s simple to use. It let’s you choose how to install and does a lot of things for you then. Want to know what it can do? Just have a look at it! It’s a shell script.

Installing the base system actually means fetching and unpacking tarballs. This is a simple and efficient method. And while it means that the files for the base system are not managed by any package manager (the programs we’re going to install later of course are!), it seems that the OpenBSD people can live with that pretty well. Upgrading the system means extracting newer tarballs and removing some obsolete files by hand.

Installing OpenBSD 5.6 tarballs

Version 5.7 of OpenBSD is due next month so at the moment 5.6 is the newest version out and I’m going to use that. After the system was installed on the drive I’m prompted for the root password and a few other things.

Some more choices of the OpenBSD installer

Trying to build pacman

Now we need the pacman sources of course. Let’s install wget to download it. That program is available as a package for OpenBSD but to get that we need to tell the package system the path to a package mirror first.

Fetching pacman source with wget

Ok. After installing some dependencies for pacman (bash and libarchive) configure was happy. So we’re ready to make!

Trying to ‘make’ pacman

Oops. Pacman obviously needs GNU make and cannot be built with BSD make. So let’s install gmake and try again.

Compilation failed – installing a new gcc

Much better. The compilation begins. But then it fails. Looks like OpenBSD’s old gcc is not capable of compiling pacman… Fortunately there’s a newer version (two of them in fact) available as packages. Let’s install one, set CC to egcc (this is what the packaged newer gcc versions are called to distinguish them from the system compiler) and re-run configure before we try to build again.

End of the line: OpenBSD does not know ‘blkcnt_t’ type!

Now that’s not cool. The compilation failed again! And this time it’s not gcc’s fault. OpenBSD simply does not know the ‘blkcnt_t’ type. As there’s no way to fix that easily, we’re stuck. Aren’t we?

What’s next?

Actually we aren’t out of luck. The coming version 5.7 supports this type! In my next post I’m going to install a snapshot and use pacman on that system. Yes, I can already tell you that it works. I’ve already taken these screenshots (and the ones for the next post) mid-march. 😉