Subject: NetBSD: For better or for worse, in good times and bad
To: None <email@example.com>
From: Robert Mohr <firstname.lastname@example.org>
Date: 10/19/2004 20:19:31
I've been using NetBSD for a number of years. I started out with an old
DECStation 3100 with release 1.4 learning the basics at the Unix command
line level, and more recently have been running both a DECStation 5000 (1.62
stable) and a SPARCStation 5 (2.0 RC3) under X. First off I'd like to
commend the NetBSD Foundation, the development team and the user community
for providing such a reliable and platform independent OS. The ability to
run a modern Unix OS on aging hardware has enabled me to learn and
experiment on boxen that were inexpensive to acquire yet still powerful
enough to provide useful functionality. The fact that the OS is free and
open-source, and provides a staggering array of free and open-source
applications as well, makes NetBSD the ideal platform for someone trying to
learn the ropes such as myself.
I fully anticipated that the learning curve would be significantly steeper
than that of commercially available, end-user oriented (read: mindless
zombie), proprietary operating systems coming out of Redmond. In fact, I
was looking for just that sort of challenge. I was quite surprised at how
easy it was to get the OS installed, and even more surprised by the
simplicity and ease of use of the pkg system for adding pre-built binary
packages to the system in a simple transparent way.
I quickly found out that while there are a huge number of applications
available in pkgsrc, only a very small number are available for any given
platform and release version as binary packages. This appears to be truer
of the old platforms such as the DEC's and SPARC's than it is for the i386
and other ports for more recent hardware. This is to be expected, as the
number of people working on any given port to older hardware is bound to be
I had fairly good success building some smaller packages from source and
learned a lot about the pkgsrc system in the process. There were no
pre-built binaries for desktop GUI applications like KDE or GNOME for either
the DECStation or SPARCStation, so I dove into building the applications
from source. It's at this point that the marriage began to hit rocky times.
I've been working at trying to get a clean build of /pkgsrc/meta-pkgs/gnome
built for well over a month now. I started on the SPARCStation with 1.62
stable, and soon had /var/db/pkg so entirely fubar that I ended up wiping
the drive and installing 2.0 RC3. After having the slate cleared, things
started out smoothly at first, but I soon encountered the first dreaded "***
Error code 1, Stop" message. Through searching the gnat database, mailing
list archives, and individual package websites for the various packages that
were failing, I've gotten past quite a number of these. Currently I'm about
a week into the current build attempt, having successfully gotten past a
failure in the mozilla-gtk2 build by installing gcc34-3.4.2 and retargeting
the Makefile to make use of this compiler (although not listed as a
dependency, at some point in the overall meta-pkgs/gnome build process,
gcc-2.95.3nb5 was installed which seemed to have broken the toolchain).
Now, I don't expect the mindless simplicity of Fedora Core's Redhat Update
Agent, Synaptic, or even that of the underlying APT and RPM packages these
package systems rely on (yes, these are primarily for installing binary
packages). That would defeat the purpose of using NetBSD as a platform for
learning the underlying machinery in today's modern UNIX OS. I didn't
however necessarily expect to be getting a crash course in C (my programming
background is in BASIC, FORTRAN, Pascal, and assembler), nor did I expect to
find myself so deep within the innards of the pkgsrc build system just to
get GNOME built and running. Perhaps I was naive.
Based on my experience so far, it seems that the pkgsrc dependency system is
inadequate to handle the demands of large, multi-package builds such as
GNOME. Or perhaps the task of updating all the dependency requirements of
such a large package to reflect the current state of pkgsrc is not automated
to the point that a build of such a package is viable.
Finally, getting to the point, I am wondering what success other users have
had with building large packages, meta or otherwise from current pkgsrc. If
nobody has ever built GNOME for SPARC (I find this hard to believe), have
other multi-package builds such as KDE, SUSE, XORG, or edesktop been
successfully built? It's entirely possible that I'm doing something wrong,
although I have spent a lot of time reading the pkgsrc documentation, as
well as man-pages for the various built-in package tools as well as a number
of the pkgtools add-ons.
Hoping to renew vows and get on with the successful marriage,
Outgoing mail is certified Virus Free.
Checked by AVG Anti-Virus (http://www.grisoft.com).
Version: 7.0.269 / Virus Database: 264.11.1 - Release Date: 10/15/2004