Contributed by deanna on from the too-much-free-time dept.
As always with OpenBSD, there is a huge amount of official documentation available for everything that will be discussed. Links will be provided and it is expected that you'll read them all before doing anything that may render your system unusable. This process requires a decent amount of system administration skills and OpenBSD knowledge; you could pick a lot of this up along the way, but you are putting your system's stability at risk. This guide is intended for hobbyists and home users -- if you need to read it, then you probably have no business doing any of this at work, in production, or on someone else's machine. The author is in no way responsible for you trashing your system, even if the instructions here are in any way at fault. This is a rough guide; it would be wise to let it sit a while then check the comments for the inevitable corrections. With that out of the way, as Richard Gabriel says: let's rock.
Upgrade to a snapshot
Go to your nearest OpenBSD mirror and upgrade to a snapshot. I find it most convenient to download the files to disk, and upgrade from there, using a less frequently updated boot CD across upgrades.
Set your PKG_PATH to the package snapshot directory of the mirror you chose for your snapshot, and use pkg_add(1) to upgrade all of your ports/packages.
Check out the source tree
The step-by-step instructions for doing this are quite clear; however, now might be a good time to get familiar with cvs commands. They are notoriously many and confusing -- watch the changes list to see even developers screwing it up. The cvs commands you'll be using the most of are checkout, update, diff, and log.
Mergemaster is a nice little port that will check the source tree for changes to configuration files, alert you of these changes, and let you choose to install the new files or merge the changes in with your existing ones. You could do this by hand, of course; however you choose to do it, it should be done.
Things get removed or replaced. A recent example is wicontrol; if you're running -current, you shouldn't even have it. It is usually ok to keep things like this around, but they make a mess. In any case you should keep your system clean so that you don't introduce more complications into the testing process. Someone has surely come up with an automated way to scan for these cases; hopefully they'll share it.
At this point your system should be ready for testing ports.
Check out ports
Get a fresh checkout of ports from CVS. You should know how to do this by now; if not, stop here and start all over.
You should read the ports list. I'll sneak in a little plug for gmane here; it allows you to read and post to the mailing lists and the entire archive over nntp, which makes the content all on-demand. This is much more manageable than receiving a flood of actual email messages to your inbox, and obviates the hated "Please Cc me, I am not on the list" entirely.
Though it's not necessary, it's cleanest to test your ports outside of the official tree, in a folder that is usually called '/usr/ports/mystuff'. Mystuff isn't just a cute name, it is recognized as part of the ports system, so everything that works in /usr/ports/subdir will work just fine if located under mystuff.
Applying patches, testing ported apps
Now, someone has posted a new port or a port upgrade to the list. Untar it in mystuff, or apply the patch. If it won't build, and you're sure it's not your fault, notify the list. If it does build, install it and start testing. There are plenty of people who test the build and packaging; what's most needed is for people to actually try to use the programs being ported. Read the docs, get an idea of what the program is supposed to do, and make sure that it does. Report success or failure to the list.
Eventually, you may want to test the port itself, rather than the program it creates. It seems that a full, new ports guide has been in the works since the epoch. For now your best bet is reading the list, the porting section on the OpenBSD web page, and the manual pages for ports, packages, make, bsd.port.mk, library-specs, packages-specs, and everything cross-referenced by these. When you have this down, you may then critique or improve others' ports. Until then, you should probably keep your hands off and just do functional testing.
Next installment: testing src and XF4.. which you, the reader, are most welcome to write and submit yourself!
(Comments are closed)