| Front | Info | Lists | Newsfeeds | Study Guide | What is BSD? | |
|
Pkgsrc on non-NetBSD interview
Interview by Jeremy C. Reed The following are email interviews with five "pkgsrc" users (non committers) who use pkgsrc on non-NetBSD systems. pkgsrc is two things: a framework for building and installing software and also tools for managing binary packages. The pkgsrc collection provides specifications and code for building over 5000 packages for several operating system platforms. The NetBSD pkgsrc developers strive to provide tools and code that is portable for many operating systems. Thank you to David, Pierre-Philipp, Eric, Gilles, and Justin for participating in this interview. 1) What packaging system (if any) were you using on your operating system? David Hopper (Mac OS X): My first OS X box was a lampshade iMac back in early 2002, may that wonderful design rest its soul. For a brief period I tried Fink, but was frustrated with the whole 'dselect' process-- it seemed that you needed to go through multiple unintuitive steps, with lots of curses screen-paging involved, just to upgrade a single package. But then I didn't invest a lot of time to becoming an efficient Fink user-- it was just for a package or two. Once OS X support was fully inlined within the pkgsrc tree (prior to this it was "Zoularis on OS X"), I moved over to it. Gosh, that was four and a half years ago now.Pierre-Philipp Braun (Linux): On Slackware Linux, there's simple compressed .tgz binaries without any real dependency management (apart ldd outputs checked against some package content browser). That's what I was using. On IRIX I was using SGI Freeware. And of course I'm using pkgsrc on NetBSD. Eric Schnoebelen (HP-UX): I didn't really use a packaging system on HP-UX prior to starting to port pkgsrc. I generally built (and patched) by hand, or, on rare occasions, used the installation depots from the HP-UX Porting Centre at the University of Utah (and other locations around the world.)Gilles Dauphin (Solaris): I use the Solaris packaging system and pkgsrc. Packages are installed at Jumpstart time. (Jumpstart is a Solaris install tool.) Justin C. Sherrill (DragonFly): On DragonFly, I had been using dfports, the override of the FreeBSD ports system.2) Why did you consider and start using pkgsrc? David Hopper (Mac OS X): I had been an active NetBSD user since late 1993, with three Alphas, an Amiga, two x86 multiproc machines and a few MIPS boxes all running NetBSD, of late sharing the same pkgsrc tree. As I was already familiar with pkgsrc, it was self-evident to add the OS X boxes to the list. After the iMac, I deployed it on my Powerbook in 2003 and just this week, on my new Mac Pro (Quad-3.0 GHz). It was lovely to see that latter one crank away on a recursive 'bmake install' of GQview. It's certainly the fastest compiling environment I've ever seen. Benchmarks will be a bit meaningless, as I normally keep current on pkgsrc and don't use the quarterly branches (so the bits change daily); I don't prefetch source files for large builds (so there's my slow DSL with which to contend); and I use a disk image on OS X as a pkgsrc source and installation drive, which can be a tiny bit slower than native disk access. But the bootstrap completed in 1 minute 33, and a pre-fetched Perl 5.8.8 compilation takes 2 minutes, 27 seconds from start to finish. But a really nice recursive build with KDE or GNOME libs in the mix, where a lot of the source allows for threaded compiling, cruises.Pierre-Philipp Braun (Linux): Slackware, to me the only well known bearable Linux, was missing some real package system. So using NetBSD's portable package system on it just made sense. There were also a few more packages than on Slackware repository plus linuxpackages.net. Not mentioning the benefit of pkgsrc's advantages like audit-packages and a clear separation of the packages from the system. Eric Schnoebelen (HP-UX): I had considerable experience with it on the NetBSD systems in use on my network. NetBSD is the dominate platform on the network, with a couple of FreeBSD systems, a Linux system or two, a Solaris system, and the HP-UX systems.Gilles Dauphin (Solaris): Approximately one year ago, I asked my co-worker for a packaging system like the FreeBSD ports. (My co-worker works on FreeBSD.) He sent me the pkgsrc URL. Before I used pkgsrc, I manually installed all free software by compiling it, looking at docs, looking at dependencies, etc. That was consuming time. The idea of automation and reliable installations came naturally. Before, I installed software in /usr/local on a server and shared them to all workstations. That was a problem when students came for lessons, because they did the same things at same time and consume (net, nfs) resources at same time, overloading our server and network. Now, all software is local to the workstations, saving network resources. And easy to install through the pkgsrc packaging system and jumpstart. I like the 'philosophy' and the concept of pkgsrc. Justin C. Sherrill (DragonFly): The 'official' packaging system for DragonFly became pkgsrc, so I switched to it at the time it became official - release 1.2, I think it was.3) What do you use pkgsrc for? servers, firewalls, development, user desktops? other? David Hopper (Mac OS X): All of it -- any time I need an open-source tool on any platform (especially OS X), I look to see if it's in pkgsrc. I usually build Perl, GIMP, GQview on any platform I find myself on, and many, many others; tcsh, emacs, python, ruby, xmms, mjpeg tools... OS X has a rich development environment and a vibrant software community, but I still find lots of nice gems in pkgsrc that in the OS X software world either cost money, are overly complicated, or are inferior in quality or features. That said, there's little reason to install something like KDE or gnome-desktop on OS X, although I have actually done it before.Pierre-Philipp Braun (Linux): I use pkgsrc for servers. I prefer to use Slackware's and linuxpackages.net binaries for (Zenwalk) desktops. I've also written an alternate Slackware package tool (replacement for slackpkg, swaret and others). Eric Schnoebelen (HP-UX): pkgsrc is in use widely across the local network. Anything used on production systems comes out of pkgsrc (or pkgsrc-wip.) There are only two user desktops, the rest are development and production servers.Gilles Dauphin (Solaris): We use it only for user desktops on sparc and amd64. /usr/pkg/bin is the first in the student's PATH. We are testing the DNS package (bind9) to replace our very old DNS server. And test is now OK :) Justin C. Sherrill (DragonFly): In my case, I use it at work for my desktop machine (DragonFly) and for my server, shiningsilence.com (also DragonFly). I also use it to generate the documentation for DragonFly; the Handbook and various articles. I also used it for my desktop machine at home until it was stolen earlier this year; I'd be using on my replacement laptop except for that it's a Mac, so it already has BSD.4) Do you use any special features of pkgsrc (such as non-root installs, pkgviews, using pkgsrc or native dependencies, custom configurations directory, USE_ABI_DEPENDS=no, quarterly stable branch, et cetera)? Please share an example or two of your usage and why? David Hopper (Mac OS X): I appreciate that pkgsrc allows advanced tools to isolate builds, but I rarely use them but to experiment. At the end of the day, I find running 'bmake update' is the tool of choice to be sufficient for everything I do. Lately I've experimented with ccache and distcc to do pkgsrc builds across the PowerPC OS X boxes at home. It's pretty cool, and rarely fails to work as intended. It really does increase build speed for larger packages and dependencies. In /etc/mk.conf this would be:PKGSRC_COMPILER=ccache distcc gcc MAKE_FLAGS+=-j6 DISTCC_HOSTS=localhost host1 host2Be sure also to place your CPU optimizations in /etc/mk.conf. For PowerPC this is what I use: CFLAGS+=-mcpu=7450 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxopt CXXFLAGS+=-mcpu=7450 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxoptI'd be interested to hear if this will work cross-platform, to use ccache and distcc to leverage the speed of the Intel OS X boxes to compile pkgsrc tools for the PPC OS X boxes. I don't know the answer to that yet, but it seems to me it would take a classic cross-compilation environment to set up. Pierre-Philipp Braun (Linux): No I'm just using standard pkgsrc commands and the bulk system. Note: we forgot to mention pkg_add -u at pkgsrccon 2006 while talking about the various update methods. Eric Schnoebelen (HP-UX): I don't make use of the special features. The feature most attractive to me is the dependency management and autobuilding of the dependencies when out of revision. I've not made use of the quarterly branches, although I probably should. I usually take the top of the tree, and then build the needed packages in a box (via pkg_comp), and install those on the system once the build is done. As I mentioned above, all production systems (web servers, news servers, mail servers) are built from pkgsrc. Admittedly, they tend to get out of revision on a regular basis, but the pkg_comp builds make it relatively easy to upgrade.Gilles Dauphin (Solaris): Not really, but: 1) I bulk-build from source in a sandbox, protecting my system from crash or wrong configuration. 2) I hack pkgsrc for building pkgsrc, creating 'virtually' two new architectures for pkgsrc: sparc64 and x86_64 for Solaris. I have my own script to build roughly 'essential' packages (games is essential for students ... and me!) especially multimedia, devel, signal processing, language, etc... all you need in a high school. I don't understand all the features of pkgsrc and use it as simple as possible. I use a 'near' quarterly stable. The current install is 2005Q4 but will switch to 2006Q3 on our ~50 amd64 workstations and ~70 sparc workstations when ready (for me). We currently are replacing all our sparcs with Sun amd64 and sparc is not our priority. For bad/unknown reasons packages are 64bits on amd64 and 32bits on sparc. Justin C. Sherrill (DragonFly): I do binary installations as much as possible from Joerg Sonnenberger's archive, and I've been planning to use the quarterly releases, but I haven't gotten to it. I don't like anything that requires extra setup with a packaging system. The big goal when using any packaging system is not to use the packaging system itself, but how quickly it can get you to the application you really want to have. With that goal in mind, the only reason to mess with these other features is to let me get to an application I couldn't install (easily) otherwise. So far, that hasn't come up. (Wandering off topic...) I think that tasks in a given software system should be expressible as a simple actions, and the more direct the process to do that action in the software system, the better it is. To give a more concrete example, if someone says "I want to upgrade this software package", they should be able to do it. With FreeBSD ports, that can be done with 'portupgrade portname', which is pretty close to encapsulating the whole desired action. In pkgsrc, upgrading can actually mean: build a replacement, delete dependencies, install the replacement, reinstall dependencies. This doesn't have a backout process, unless more steps are added to create packages from the old software versions.5) Do you also use pkgsrc on other operating systems? Which one(s)? David Hopper (Mac OS X): NetBSD and Windows (via Interix, aka Microsoft Services for UNIX: see http://www.duh.org/interix/hotfixes.php). I have Fedora and Ubuntu deployed as well, but for laziness' sake I rely on native package tools for those.Pierre-Philipp Braun (Linux): Just on Slackware Linux and NetBSD. Although I tried it successfully on FreeBSD once. Eric Schnoebelen (HP-UX): NetBSD, Linux, HP-UX, Solaris, and FreeBSD. Right now, the dominate OS's are NetBSD and HP-UX.Gilles Dauphin (Solaris): No. But, now, my co-worker asked me how pkgsrc works and if exists on FreeBSD... Justin C. Sherrill (DragonFly): No.6) How do you manage using pkgsrc and your native operating system's own software? David Hopper (Mac OS X): The nice thing about having /pkg, /pkgsrc, and /pkgdb on an HFS+ case-sensitive disk image in OS X, is that when it is unmounted, there isn't a trace of pkgsrc on your system. Once you mount the disk image, you immediately have access to the source tree, libraries, and all binaries you have installed via pkgsrc. It's almost like an instantaneous 'Clean Everything' / 'Install Everything' feature. Since the disk image is in your path, you get everything right away. When it's not there, the OS X environment doesn't care. Put your .dmg image on a USB drive, take it with you, plug it in to a different machine. As long as the OS X version is mostly the same, and the processor architecture is the same, you can take your entire pkgsrc software environment with you. Just update $PATH and you're set. Works for NFS mounts too, but I find disk space is cheaper than time spent dealing with NFS quirks and network timeouts.Pierre-Philipp Braun (Linux): I did reduce Slackware's default install accordingly, even providing a lighter ISO image. Eric Schnoebelen (HP-UX): On NetBSD, it's not an issue. On HP-UX, pkgsrc builds/installs into it's own tree, well seperated from the HP provided software. HP provided software is managed via SD-UX (a very powerful package distribution mechanism in its own right) and the pkgsrc software managed by pkgsrc.Gilles Dauphin (Solaris): All software is installed at installation time via Jumpstart including pkgsrc. PATH looks first at pkgsrc, second at OS (/usr/bin and /usr/sfw/bin...), and third at my manual build (/usr/local, old /usr/local/X11R*). Some packages do not work or too complex to configure (at ENST), so I prefer to keep in /usr/local, i.e. old xemacs. Justin C. Sherrill (DragonFly): Since DragonFly 'officially' uses pkgsrc, there isn't the conflicts/confusion that I would assume comes along on platforms like Sun, where the existing operating system is already trying to provide similar tools built-in.7) Any suggestions, tools, or techniques to share with other pkgsrc users? David Hopper (Mac OS X): If you ride along with the -current pkgsrc on OS X, there will be compilation errors from time to time. If there is an error in a dependency, most of the time you can fix it yourself within the pkgsrc tree, in the failing dependency's work directory, by simply building that tool manually via 'configure && bmake' (or, in some cases, you must use 'gmake' or just 'make' to complete the build, or add flags to ./configure). Once that source successfully builds, just leave all bits in place, and back out to the dependency's pkgsrc directory (e.g. graphics/mjpegtools). Do a 'bmake' from there and the pkgsrc compile should work. Then go restart the original 'bmake update'. I find this works for a majority of failures, and when it doesn't I simply wait for the upstream patch, then cvs update again. I find these types of errors to be rare when working with the stable quarterly branches.Pierre-Philipp Braun (Linux): "make clean-depends" to quickly show the dependencies instead of viewing the Makefile. Eric Schnoebelen (HP-UX): Not off of the top of my head. After recently responding about supporting HP-UX in pkgsrc, I was approached about becoming a developer/committer for the purpose of maintaining the support. Following through with the access is currently in progress.Gilles Dauphin (Solaris): Sorry, not yet. Justin C. Sherrill (DragonFly): pkgdepgraph can produce some pretty graphs for dependencies. pkgmanager is apparently a very nice GUI tool for pkgsrc management, though I haven't tried it myself.8) Any suggestions to share with other pkgsrc developers? David Hopper (Mac OS X): Stay the course, you people are doing an amazing job. I think the only thing I might possibly have on my wish list is to have some kind of Wiki that keeps up with the undocumented commands and features of pkgsrc -- kind of a one-stop shop that explains everything from pkgviews to all the different mk.conf flags. The pkgsrc guide is very nice, but the specifics of mk.conf and descriptions of experimental features are "in the code" right now. Tough for users to ferret out.Pierre-Philipp Braun (Linux): Although I'm providing bulks for Slackware, I'm new to pkgsrc development, so unless you're really a beginner, you won't have much to learn from me :) And I know my interviewer is far from being a beginner :) Oh, yes, a request: please make the pkgsrc guide shorter/understandable/stupid/straightforward/simple... I like the "no hype required" saying. Not in the sense of "we don't need marketing". I rather consider that saying like "we don't need no blablabla, we're just efficient and we straightly get to the point". I like the "by example" kind of tutorials. Eric Schnoebelen (HP-UX): Nothing that most of them don't already know. Using the pkg_* tools, especially those in pkgsrc/pkgtools is a wonderful aid in developing and importing new packages. A wish would be for some of the portions of the documentation to be more complete. I occasionally have a hard time figuring out what's happening in the background, even after reading the source.Gilles Dauphin (Solaris): Yes, keep cool ;) Justin C. Sherrill (DragonFly): I'd like to see the binary installation of pkgsrc more able to stand on its own. Right now, you can use pkgsrc mostly with pkgsrc packages, but there's some packages that don't get built because of license restrictions. (Some of those packages are buildable/redistributable, but bulk builds seem to skip anything with any sort of license restriction at all.) The upgrade or management tools I've looked at, like pkg_chk or pkgdepgraph, assume there's a local pkgsrc tree on the disk. Keeping the entire file hierarchy up to date eats up space, time, and bandwidth, and isn't needed when the binary packages are available.9) What is your job title and/or other very quick description of your background? David Hopper (Mac OS X): Oh, I've been at NeXT Computer, and Microsoft, and I've been a NetBSD user since the beginning. For 10 years I owned a company (Global Event Services, Inc.) that implemented networks, network security, and machine image deployments for technical conferences and tradeshows. This year I'm taking a break to spend more time with my three-year-old, and to revisit an old interest of mine: digital and analog film production and editing.Pierre-Philipp Braun (Linux): I'm an IT specialist (analyste d'exploitation) at Nethence solutions, Europe/Paris. However, I studied psychology in the first place. Maybe this helped, by theoretical points of views, to choose NetBSD as my operating system of choice. I'm quite as much passionate in UNIX as I am in (brutal) psychology and philosophies. Eric Schnoebelen (HP-UX): Job title? Owner... Job description: Contract UNIX software developer. Background: I've done software development on UNIX based systems since 1983 (or so). I've worked with BSD derived systems for many of those years, including 5 years at the hardware vendor CONVEX Computer, where I did OS and utilities development, and maintained and enhanced the installation packaging and packaging tools. I've been doing contract development/consulting since 1998. Currently, I'm on contract with Hewlett Packard, developing and packaging software for release with their quarterly applications releases.Gilles Dauphin (Solaris): I am system admin at ENST, a high school in Paris. Four years of university. Born in 1953. I wrote some software, most significant is mMosaic (Multicast Mosaic). Justin C. Sherrill (DragonFly): I'm a network engineer at Current Communication, a provider of broadband over power line services. Most of what I do is automate processes and create reports from the variety of network devices and Linux servers the company has out in the field. No pkgsrc involved on those systems, though goodness knows I've wished for it when dealing with Red Hat Network.
DiscussionDiscuss this article below.
PKGSRC
|
BSD Links · Advocacy· Drivers · Events · Flavours · FAQs · Guides · Programming · Security · Software · User Groups |
