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

On Tue, Dec 09, 2003 at 03:24:33PM -0800, Jason Thorpe wrote:
>=20
> On Dec 9, 2003, at 3:20 PM, Bill Studenmund wrote:
>=20
> >I said "support" as in "we help you do it" as in we keep patches=20
> >around,
> >and update them as the source package changes. That's pkgsrc, is it=20
> >not?
> >I'm saying that I don't think we need to impliment a SECOND way of=20
> >keeping
> >track of 3rd party patches in addition to pkgsrc.
>=20
> My point is that it is TOTALLY unreasonable to require patches to=20
> arbitrary 3rd-party software in order to make their shared libraries=20
> work properly.

Jason, what libraries are we talking about?

What libraries are people using that aren't in pkgsrc for which the shared
library numbers really mean something? I know that if you ran a project,
lib numbers would mean something. However most 3rd party development
projects I am familiar with don't pay attention to versioning. They make=20
libraries then they make programs. If you update, you recompile=20
everything.

> All of that can be avoided by not bumping the major on a select set of=20
> important shared libraries.

To avoid the problem we're talking about, we can't bump _any_ shared
library versions.  Since we don't know what these libraries are, we don't
know what libraries they are using. We (NetBSD) have bumped a number of=20
library majors, so we may well have already caused the mess you are=20
wanting to avoid.

Also, with gcc 3, haven't we changed libstdc++ and thus its major number?=
=20
Thus haven't we already inflicted this pain on c++ libraries?

> It baffles me why people seem to be insisting on looking for a solution=
=20
> to this problem when the problem can be completely, and almost totally=20
> painlessly, avoided in the first place!

Because times change, and too many of the reasons abjectly against it
smell of FUD. While keeping the compat stuff around isn't a pain now, over
time it may well become one. The fact it will grow without bound by=20
definition indicates that we probably will want to make a change someday.

All that really needs to be said is that we don't need to bump libc's=20
version until we would see significant gains, like shaving 33% or more off=
=20
of libc's size. Or 50%. That will both stop the discussion probably for a=
=20
decade, and leave the door open for us to actually bump the version if=20
we decide there's a good gain.

Take care,

Bill

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

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

iD8DBQE/1mZcWz+3JHUci9cRAqczAJ9QsuvwmAchCGPe03YTfcF9nxmaewCfe3hk
X87BMDsRmhebyuvMyyxBYug=
=jeoY
-----END PGP SIGNATURE-----

--Q0rSlbzrZN6k9QnT--