--KdquIMZPjGJQvRdI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 09, 2003 at 08:54:30AM +1100, matthew green wrote:
>   =20
>    > Now let's say libother is a 3rd-party library, which is used on many=
=20
>    > different operating systems.  How easy do you think it will be to ge=
t=20
>    > the libother maintainers to bump their shared library version?  How=
=20
>    > easy do you think it will be to maintain a local patch for all etern=
ity=20
>    > that keeps the shared library version ahead +1 of the stock libother=
=20
>    > version (and only for specific versions of NetBSD)?
>    >=20
>    > How easy do you think it will be to maintain such patches for hundre=
ds=20
>    > (or even thousands) of 3rd-party libraries?
>   =20
>    That part is easy! pkgsrc already does this for thousands of libraries=
 now
>    (as part of the patches for the enclosing packages).
>=20
>=20
> 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=
=20
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=
=20
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=
=20
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)=
=20
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
do it.

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=
=20
years, but sooner than never. :-)

One of the things I'm assuming we'd be able to do is be able to compile an=
=20
old libc.so.12.X on a system that has libc.so.13.Y. Obviously there'd need=
=20
to be some explicit goop at compile time.

Take care,

Bill

--KdquIMZPjGJQvRdI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/1RQTWz+3JHUci9cRAmPzAKCPnoG//zJLzv63wvlQrEbJ+40DKACdHn+b
DzcU+du+v4x6T5fSYyWaX6g=
=H5js
-----END PGP SIGNATURE-----

--KdquIMZPjGJQvRdI--