Subject: Re: NetBSD 2.0 release date
To: matthew green <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 12/08/2003 16:15:15
Content-Type: text/plain; charset=us-ascii
On Tue, Dec 09, 2003 at 08:54:30AM +1100, matthew green wrote:
> > Now let's say libother is a 3rd-party library, which is used on many=
> > different operating systems. How easy do you think it will be to ge=
> > the libother maintainers to bump their shared library version? How=
> > easy do you think it will be to maintain a local patch for all etern=
> > that keeps the shared library version ahead +1 of the stock libother=
> > version (and only for specific versions of NetBSD)?
> > How easy do you think it will be to maintain such patches for hundre=
> > (or even thousands) of 3rd-party libraries?
> That part is easy! pkgsrc already does this for thousands of libraries=
> (as part of the patches for the enclosing packages).
> pkgsrc can't solve the problem unless you're going to make it so that
> the major version of a shlib +=3D (libc version - 12) ? otherwise you're
> going to end up bumping the shlib on old (eg, 1.6) platforms, and other
> non-netbsd hosts.
I don't think that'd be a problem. The pkgsrc folks have done things much=
more difficult than this. Plus, since all libraries would be facing the=20
problem, it only has to be solved once then cloned.
However, I'm not really sure we need to do this (for pkgsrc). Far too many=
package developers don't maintain proper library versioning, so pkgsrc=20
can't depend on backwards compat of the type we expect from our system=20
libraries. So libc 12 vs libc 13 is just one of many problems with 3rd=20
party libraries. And ripple-upgrade, the common pkgsrc upgrade path, will=
work fine with crossing a libc 12 -> 13 transition.
> at the end of the day, what's the benefit? programs don't work anymore.
As above, the majority of 3rd party packages (that I've looked closely at)=
don't internally maintain the kind of library versioning we're talking=20
about for our system libraries. So why are we stressing about adding a=20
library versioning to them that they won't support?
> why do people want this? all it causes is pain.
Because right now we have an unending growth path. We will keep bloating=20
libc over time. As opposed to kernels, there is no way to turn off=20
backwards compat (and I think that's fine), so it keeps getting fatter &=20
fatter. Eventually we will want to trim the fat.
Yes, it will be painful. But realistically, I think it can be less painful
than the transition to ELF. And since we aren't pressed about doing it, we
can put what we need in place for the transition a whole release before we
I'm not saying we are to the point where I think we should do this, I'm=20
explaining why I think we will want to do this someday. Maybe in ten more=
years, but sooner than never. :-)
One of the things I'm assuming we'd be able to do is be able to compile an=
old libc.so.12.X on a system that has libc.so.13.Y. Obviously there'd need=
to be some explicit goop at compile time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----