3 ms·

I wish OpenBSD had more unofficial documentation on this topic. I am designing some python software application that configures custom hardware. Since the app

I wish OpenBSD had more unofficial documentation on this topic. 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.

anjbe 7y ago
> 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? 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 https://www.openbsd.org/faq/ports/guide.html#PortsChecklist
notaplumber 7y ago
Distributing binary packages outside of OpenBSD's official repository is generally discouraged, as you'll need users to install your public key (packages must be signed, unsigned packages are rejected by pkg_add), and set a custom installurl. This is unsafe as you could be providing other packages overriding the official repo. 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.
- elevation 7y ago
  Since the application is useless without a specific set of hardware peripherals, it seems impolite to clutter the ports namespace and add tasks to OpenBSD infrastructure. The software is only useful when run on an instance of a specific hardware appliance. 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.

anjbe 7y ago

> 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? 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 https://www.openbsd.org/faq/ports/guide.html#PortsChecklist

notaplumber 7y ago

Distributing binary packages outside of OpenBSD's official repository is generally discouraged, as you'll need users to install your public key (packages must be signed, unsigned packages are rejected by pkg_add), and set a custom installurl. This is unsafe as you could be providing other packages overriding the official repo. 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.

elevation 7y ago
Since the application is useless without a specific set of hardware peripherals, it seems impolite to clutter the ports namespace and add tasks to OpenBSD infrastructure. The software is only useful when run on an instance of a specific hardware appliance. 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.