Subject: Using binary packages on -current
To: None <>
From: Chapman Flack <>
List: current-users
Date: 04/26/2006 00:21:23
In the time that I've been running stable NetBSD releases,
I've enjoyed the convenience of installing binary packages.
In moving a machine now to -current I wonder if current-users
typically just build everything from source, or if there are
ways of making do with, say, the binary packages built for
the most recent stable release. I've installed some 3.0
packages and run into shared libs that are part of the base
system that have had their major versions bumped.

Q: COMPAT_30 is enabled in the kernel. I suppose I could
   install the older shared libraries from a 3.0 distribution.
   Would they go in the usual places, or somewhere under /emul
   as in the COMPAT_IBCS2 arrangements?  Looking through
   kern/exec_conf.c, it seems that the intra-NetBSD COMPAT_<nn>
   options do not really involve a distinct "emulation mode"
   for a process the way the IBCS2 or Linux compatibility does.
   Am I right?  (This doesn't seem documented so well; there are
   compat_foo(8) man pages when foo is another OS, but not for
   foo == earlier NetBSD).

Q: If I'm right above, then just having the older libraries
   around and COMPAT_30 enabled in the kernel ought to let some
   3.0 binary packages run.  But what if they then serve as
   dependencies for another package I build from source, and
   I wind up with an executable ldd shows as referencing two
   different major versions of a single library?  Is there any
   sane way to deal with such things?  Or should I just bite
   the bullet and do source builds of everything?

Q: Is there a regular scheme for announcing (on current-users
   or elsewhere) when a shared lib that's in the base system
   gets a version bump?  For example, CVS shows that the
   change to src/lib/libz/shlib_version was 14 January, but
   I didn't see it mentioned in UPDATING and I don't know if
   there is some existing place to look where all library
   bumps would be mentioned.  Some CVS script could perhaps
   automate the work by noting commits that affect a
   shlib_version file.

Sorry for the newbie-esque questions; I can probably help
flesh out the documentation on these points once I'm sure
of the details, having the memory fresh in my mind of where
*I* looked hoping to find them.