Package Management in OpenBSD
unixsheikh.com
unixsheikh.com
> People on FreeBSD use poudriere for that, but that doesn't exist for OpenBSD.
This is no longer true. If people want to build their own -stable packages, they can use dpb(8), the distributed ports builder. This is used by the official ports build clusters.
Many OpenBSD developers would like for there to be -stable packages, and that may even happen again someday. But it requires a level of commitment and coordination from many people, who might be otherwise preoccupied (ports development happens on -current). All I can say on that front is stay tuned.
I am designing some python software application that configures custom hardware. Since the application requires specific hardware peripherals and an exotic network configuration, it makes sense to package it on a purpose-built appliance.
The software application works on any unix-like environment with python3 available, so OpenBSD and Debian are both candidates; both support my hardware platform and both receive security updates. Debian can be pared down to a minimal install to harden it, and OpenBSD has proactive security features like pledge() that could be integrated into the application code. Either way, I'm mostly looking for a not-insecure OS that can run some python code.
While OpenBSD's security is venerable, debian stands out in software packaging software. Building a .deb, signing it with a GPG key, and installing/removing it is covered by numerous tutorials. On debian, `apt-get' can install this package, and later remove every file.
But figuring out the ideal way to make an equivalent package for OpenBSD has been less straightforward. The ports tutorial says all ports need to be built with X-windows running on the build machine. Does that still apply to python3 code? What if I have a compiled utility to add to the package later? There is a man page for 'pkg_create' but there's hardly any tutorials that reference it or how to use it.
On freenode, #openbsd has been full of incredulous, unhelpful tips like "why would you use a package manager when you could just untar an archive onto root to install your application?"
As much as I respect the OpenBSD team, it's frustrating when you try to perform what should be a straightforward task but google and IRC make you feel like you're the first person who's ever tried it.
X needs to be installed, not necessarily running. It’s needed because some packages, perhaps dependencies of the port you’re building, depend on X libraries.
> There is a man page for 'pkg_create' but there's hardly any tutorials that reference it or how to use it.
pkg_create is not a tool you generally run by hand. Packages for OpenBSD are always developed from within the ports framework. pkg_create is run in the background by the "make package" step: https://www.openbsd.org/faq/ports/guide.html#PortsChecklist
In general, ports should be submitted to the ports@ mailing list, in which case packages are built and signed by the OpenBSD project instead. This way they can be built on multiple architectures, and be available for release and -current users.
If you do intend to distribute packages, you still need to use the ports infrastructure for it, ports exist to build packages. They should not be manually constructed.
Also, since the application may have its own security flaws, it would be ideal for my org to have our own package server and signing key to serve the application in packaged form, so that critical application updates can be published independent of the OpenBSD release schedule. It would not be hard to configure each appliance to trust the 3rd party package server at manufacture time.
This use case is well covered by something like a ubuntu's PPA infrastructure, which avoid namespace clutter while allowing 3rd parties to securely provide packages with independent update schedules and explicitly avoids the assumption of support from distribution developers.
I really like OpenBSD as a user, but there doesn't seem to be a good supported workflow for OpenBSD as an appliance.
Stable would be much better here. The system just works, is always on when I open the lid and connects to the wifi fast. A perfect system for Sunday morning HN reading marathons.