In article <444EF543.4020602@anastigmatix.net>,
Chapman Flack  <nblists@anastigmatix.net> wrote:
>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).

This is because you don't need to do anything. The current libc
and the kernel take care of the compatibility code.

>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?

You just need COMPAT_30 in the kernel. The libraries should work.

>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.

That would be a good idea. Yes, you would need the older libraries
to run binaries against them if there was a major version change.

>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.

These are good questions :-)

christos