Showing 5 posts
For a couple of years or so, I have been hosting my open source projects in Google Code. The time to jump ship has come. The major reason for this move is that Google Code stopped supporting file downloads three weeks ago. This is unfortunate given that "binary" releases are a must for proper software distribution. Sure, I could use a third-party service like Bintray to offer the downloads, but I'd rather consolidate all project data in a single location.
Over a year ago, I developed two command line utilities for NetBSD (sysbuild and sysupgrade) and a supporting library for the two tools (shtk). These were all introduced in their corresponding blog posts —Introducing sysbuild for NetBSD, Introducing sysupgrade for NetBSD and Introducing shtk— and since then I have heard good comments about them. About a couple of weeks ago, I started working on the much-needed rewrite of pkg_comp and a supporting standalone tool.
Have you ever wanted to have a collection of ready-to-use modules for shell scripts? I have, particularly because I keep reimplementing the same functions over and over and over and over again whenever I write non-trivial shell scripts, and I'm tired of doing so. That's why I have just abstracted all the common code in the aforementioned tools and put it into a new package called the "Shell Toolkit", or shtk for short.
Over the last two weeks, you might have had fun rolling your own NetBSD binary releases with sysbuild. But what fun is that if you have no trivial way of upgrading your existing NetBSD installation to a newer version? Upgrading NetBSD to a newer version from distribution sets generally looks like the following; Fetch new distribution sets (or roll your own).Upgrade the kernel.Unpack the distribution sets over the root directory, without fat-fingering the command and unpacking etc.
NetBSD's build system is close to awesome: after checking a source tree out from CVS on virtually any Unix-like operating sytem, building a full NetBSD release for any of the supported platforms is as simple as running the build.sh script with the right arguments. There are, however, a few things that would deserve automation in this process, but that are not in build.sh's domain to solve. These are: Fetching and keeping the source tree up to date: interacting with CVS is still the responsibility of the user.