From owner-freebsd-commit Mon Jan 8 00:45:41 1996 Return-Path: owner-commit Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA22851 for freebsd-commit-outgoing; Mon, 8 Jan 1996 00:45:41 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA22836 for cvs-all-outgoing; Mon, 8 Jan 1996 00:45:35 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA22803 for cvs-user-outgoing; Mon, 8 Jan 1996 00:45:29 -0800 (PST) Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA22781 Mon, 8 Jan 1996 00:45:16 -0800 (PST) Received: (from peter@localhost) by jhome.DIALix.COM (8.7.3/8.7.3) id QAA00547; Mon, 8 Jan 1996 16:44:47 +0800 (WST) Date: Mon, 8 Jan 1996 16:44:47 +0800 (WST) From: Peter Wemm To: "Jordan K. Hubbard" cc: CVS-committers@freefall.freebsd.org, cvs-user@freefall.freebsd.org Subject: Re: cvs commit: src/release/scripts bin-install.sh In-Reply-To: <22497.821086433@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-commit@FreeBSD.ORG Precedence: bulk On Sun, 7 Jan 1996, Jordan K. Hubbard wrote: > > Speaking of these, I was a bit disturbed when I saw the compat20.tgz file > > - it had a lot of libXXX.so.2.0 libs in there, and the install script > > seemed to be splatting all those over the top of the /usr/lib directory.. > > For example, it was splatting a 2.0 libutil.so.2.0 over the top of a 2.1 > > /usr/lib/libutil.so.2.0 > > Yep! > > I talked about this in the early days of 2.1, when others noticed that > the compat* dists seemed a little haphazardly put together and > exhibited the side-effects in question. All I can say in my own > defence is that I never really had time to do the compat libs at all, > and I warned people several times that if somebody didn't volunteer to > take that piece and make sure it was correct, I was just going to end > up having to throw something together at the last minute. > > And I did ask in May.. :-) > > To: current@freefall.cdrom.com > Subject: I still need a compat20 distribution! > Date: Sat, 27 May 1995 20:42:19 -0700 > Message-ID: <21940.801632539@freefall.cdrom.com> > From: "Jordan K. Hubbard" > Sender: current-owner@FreeBSD.org > Precedence: bulk > > It can be a single gzip'd tarball for all I care, but I really need > somebody to make a `compat20dist' that extracts relative to /. > > I'd do it myself, but I don't have the time to go chasing down all the > 2.0 compatability bits right now, so if you want to see support for > 2.0 binaries "out of the box" in 2.0.5, please consider stepping ^^^^^ > forward and making this distribution for me! > > Thanks! > > Jordan Heh. Oh well, I can pleady "Not Guilty!" - I was only just starting to sniff around back then. My research suggests that we need the following libs from 2.0-RELEASE in a compat20.tgz dist: libforms.so.2.0 libncurses.so.2.0 libdialog.so.2.0 libg++.so.2.0 libreadline.so.2.0 That's it! All these libraries jumped major revision to libblah.so.3.x in 2.0.5. We need no new libraries from 2.0.5, as no new major revision changes were made. When we start thinking about a 2.2 release, we will need the 2.1-REL (or 2.1.1-REL) libgcc.so.261.0, because that's apparently no longer being built shared on 2.2-CURRENT. In case anybody was wondering, 2.1-REL has libtermlib.so.2.1 - we do *NOT* need libtermlib.so.2.0 unless we really screwed something up. The minor revision means that functionality was added, not changed. Incidently, I dont think ld.so would ever pull in termlib.so.2.0 if 2.1 was present, because ld.so.cache will list "termlib.so.2 -> termlib.so.2.1" That huge big list of 2.0 libraries that's spamming the latest 2.1 version (remember the telnet undefined symbol problem?) needs to go on a big diet. :-) -Peter