Chapman Flack <nblists@anastigmatix.net> writes:

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

I have done both.

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

I'd put them in /usr/lib.  This is where they'd be if you installed
3.0 and then upgraded to current, as the upgrade doesn't rm the
previous libraries.

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

That's right.   COMPAT_30 just provides system calls that were present
in 3.0 but not in current; programs are still running as NetBSD
programs, not as an emulation.

FreeBSD used to have a way to install the compat libs for older
releases.

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

I don't believe there's a sane way to mix.  But this isn't about 3.0
vs current - it's a general issue about shared libraries.  The same
would occur with a major bump in e.g. libjpg.  So on all systems, you
pretty much either need to use all binary packages from the same
build, or build them all from source.  If the binaries are built for
your NetBSD branch, then you can mix binaries with builds from the
same pkgsrc branch.  In that case, you'll run into trouble if pkgsrc
has an ABI change.  This happens all the time on pkgsrc head, but
isn't supposed to happen on quarterly branches.

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

If one is updating from source this isn't an issue.  But perhaps it
would be good to list shlib major bumps in UPDATING anyway.

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

No problem - your questions are quite clueful and you've identified
something that isn't well explained.

Perhaps there should be packages that have the old shared libraries.
It would be nice to have a script that unpacks sets for an old
release, and looks for shlibs that don't exist in the new tree, where
exist means same major and perhaps higher minor.   Then one could make
a pkg for a script that fetches the old release and merges in older libs.

I don't usually notice this because I'm mostly running systems that
have been updated over time, some from as far back as 1.6.  But when I
installed current in a domU and used 3.0 packages I ran into this
issue.  I just scp'd over the shlibs as I noticed them missing, since
the machine had a limited role and I don't add stuff to it.

-- 
        Greg Troxel <gdt@ir.bbn.com>