From owner-cvs-all Fri Aug 20 12:16:33 1999 Delivered-To: cvs-all@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 8F8B9153EB; Fri, 20 Aug 1999 12:16:27 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-3-18.ucdavis.edu [169.237.17.18]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id MAA61253; Fri, 20 Aug 1999 12:16:24 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id MAA55869; Fri, 20 Aug 1999 12:16:21 -0700 (PDT) (envelope-from obrien) Date: Fri, 20 Aug 1999 12:16:21 -0700 From: "David O'Brien" To: Peter Wemm Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/include histedit.h src/lib/libedit Makefile editline.3 el.c el.h Message-ID: <19990820121621.C76112@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <19990820110114.Y76112@dragon.nuxi.com> <19990820182100.9A7781C9F@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <19990820182100.9A7781C9F@overcee.netplex.com.au>; from Peter Wemm on Sat, Aug 21, 1999 at 02:21:00AM +0800 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > With stuff using libedit, in /usr/src, the fix is also deterministic. If you With libedit in this, yes. But what about ports? I am trying to updated and codify the policy current so the Handbook can be updated. So we need a clear policy. > Regarding libreadline, the major was bumped because it wasn't compatable > with the old version. The data structs had changed, it wasn't just 'add > a few symbols' like with libedit. That wasn't my understanding of the libreadline changes. The ChangeLog only talked about added global vars and a new function. Using a /usr/bin/bc linked with libreadline.so.3, actually runs fine with libreadline.so.4 if you make a link from it to libreadline.so.3. Thus using this rull, ache shouldn't have bumped the major version number. With other situations, we will get error if we either bump or not. As someone said in the stable list: Which failure is better: An error that you don't have a recent enough version of the library, or one that the routine foo() can't be found at run time? we should come into agreement on the answer. > If yes, then no bump, especially when the only binaries using it are > those that we provide right alongside in the source tree. But the recent libc_r changes (w/o bump) in -STABLE are more used by external programs than those in /usr/src/. When deischen did a little MFC action (23 Jul 1999), asked in the stable list about bumping the lib version and [AFAIK] got conflicting opinions from jkh and jb. It is my opinion libc_r in -STABLE needs a bump ASAP. As a reminder, here is his commit message: MFC: removed -DNOPOLL. Note that unlike -current, the libc_r library version remains at 3. If you are building dynamically linked apps that now want to use poll, keep in mind that they will not be usable with previous versions of libc_r.so.3 (which lack the wrapped poll()). The same change in -CURRENT got a major version bump: > Hmmm. The internals may be opaque but you bumped the revision > number for *some* reason that involved changing the interface or > there'd have been no reason to bump the number, si senor? :-) I bumped the version number because the implementation changed from being based on select() to poll(). RELENG_3 should be changed to match -CURRENT. Enjoy! -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message