Subject: Using binary packages on -current
To: None <current-users@NetBSD.org>
From: Chapman Flack <nblists@anastigmatix.net>
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.
-Chap