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

On Thu, Dec 04, 2003 at 11:30:13AM -0800, Greywolf wrote:
> Thus spake Bill Studenmund ("BS> ") sometime Today...
>=20
> BS> Also, I think getting multi-CPU operation working right will take a f=
ew
> BS> itterations, and quite a lot of testing. I'd expect it'd take 4 to 6
> BS> months to get right. 2.0 is behind schedule as it is, so I think it'd=
 be
> BS> best to just ship 2.0 as we have it now.
>=20
> Of course, it would be.  After all, isn't the massive shakedown what a
> dot-zero release is all about, anyway? 8-D

Such confidence!

> Don't mind me, I'm just being flip.  I'm really looking forward to
> it whenever it happens to get released; until then, I'm happily compiling
> -current and running it when feasible.
>=20
> I have a question, though -- since we're migrating to 2.0, the major
> bump represents, to me, a new starting ground, a new plateau, more
> or less fresh and clean.  Do we intend to be backward compatible with
> 1.x, or can we just declare a cut-off point and move forward with a bit
> less baggage (such as, i.e., libc.so.12)?
>=20
> Or will that be 3.0 material, whenever we advance sufficiently to the
> point that we can bump our major number again (which I see libc's major
> bump as being the cause rather than an effect thereof :) )?
>=20
> [...or do we intend to ride libc v12 all the way out to 12.9999 or whatev=
er
> it's capable of handling?]

I'm not sure. Bumping libc's version number will be a BIG BIG deal. We=20
probably will want to do it when libc's version number gets to like 300 or=
=20
500, but it'll take quite a bit of logistical care.

When we bump libc's version, we will be bumping EVERY library's version.
Even if a library currently doesn't depend on libc now, we'll want to do
this so we don't screw current programs in the future. Say we later add
something to that library that isn't in libc v12. We screw any older=20
program that is using it that still uses v12.

In the past, we've had packages in pkgsrc that supply the obsoleted=20
libraries. For a libc change, I think we'd actually need to supply them=20
ourselves, for at least a full release if not two. So that'd mean src/lib=
=20
would double (or more accurately it'd be cloned). I think we'd want syspkg=
=20
up to speed at that point too.

Take care,

Bill

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

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

iD8DBQE/z9iQWz+3JHUci9cRAiivAKCT7KzDZ93RdgMKN3VueEwYkcvBTgCeNkRn
agiBDQyk0viO