3 ms·
Distributing binary packages outside of OpenBSD's official repository is generally discouraged, as you'll need users to install your public key (packages must b
by 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 agoSince 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.