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

On Mon, Dec 08, 2003 at 09:03:01AM -0800, Jason Thorpe wrote:
>=20
> On Dec 8, 2003, at 8:42 AM, John Franklin wrote:
>=20
> >On Dec 7, 2003, at 3:06 PM, Jason Thorpe wrote:
> >>Version checks will not solve the problem.  Sigh, I guess I'll have=20
> >>to repeat the crux of the problem *again*.
> >>
> >>Consider this:
> >>
> >>	program foo depends on libc.13 and libother.0
> >>
> >>	libother.0 depends on libc.12
> >>
> >>*EVEN IF* you have 100% complete inter-library version consistency=20
> >>checking, you still lose in this situation.  What if foo and libother=
=20
> >>both call function zap(), and zap() is one of the things that had an=20
> >>ABI change between the two libc versions?
> >
> >How would this program even link?  Wouldn't the linker return a storm=20
> >of duplicate symbols as it tries to resolve through both versions of=20
> >libc?
>=20
> What if program foo was compiled on a different host, and you received=20
> it as a binary?  What if, on that other hose, libother.0 had a recorded=
=20
> dependency on libc.13 (i.e. it is a "fresh install"), but you are=20
> running it on a host that has an older libother.0 that has the libc.12=20
> dependency.
>=20
> This is a totally normal, acceptable situation that should work=20
> (assuming the library minor numbers are the same).
>=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 get=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 eternity=
=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 hundreds=20
> (or even thousands) of 3rd-party libraries?

That part is easy! pkgsrc already does this for thousands of libraries now
(as part of the patches for the enclosing packages).

Given the magic I've seen the pkgsrc folks perform, I'm sure they could=20
come up with a way to deal with a libc version bump. Perhaps tagging=20
packages as being "libc v12" or "libc v13". Or, now that pkgsrc is=20
branched at a release, we do the libc bump after a release and keep=20
different package versions on the "last release" branch (libc v12) and=20
pkgsrc head (libc v13).

Since over 99.9% (if not more) of the 3rd party source we use today is in=
=20
pkgsrc, I think we now have the control we need to deal with a libc=20
version bump.

Also, Jason, you're assuming that 3rd party packages are performing good
shared-lib management; that they are as good as we would both strive to be
and expect of them. My experience has been that a number of them aren't.
They freely remove symbols or change them (both of which should mean a
version bump), without a care. Given that they don't care about backwards
compat, I don't think we need to (for those packages). For them, we only
need to worry about NetBSD binary packages being segragated by libc
version number.

As I said in a note which seems to have not made it to the list ( :-(  ),=
=20
I think we now are in a place to reassess the problems surounding a libc=20
version bump. In addition to pkgsrc, we now are using ELF, are running=20
current gcc/binutils, and have a lot of gcc/binutils expertise (so once we=
=20
figure out the right way to fix the problem, we have folks who could do=20
it). That's a lot better a place than we were last time I remember this=20
coming up (which was NetBSD 1.2 or 1.3 if I recall).

I don't think we need to do it for a few more years yet, but I think it is
something we can now tackle (right) when we choose to.

Take care,

Bill

--L6iaP+gRLNZHKoI4
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/1McdWz+3JHUci9cRAtrTAKCNaFvjMFhfIExcRfqQm64y2R7EWgCfZSZV
pizKID8IAS0TxPS/9CwYfsM=
=U0Nm
-----END PGP SIGNATURE-----

--L6iaP+gRLNZHKoI4--