Subject: Re: Using binary packages on -current
To: None <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 04/26/2006 17:00:50
In article <444EF543.email@example.com>,
Chapman Flack <firstname.lastname@example.org> 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 :-)