Date: Fri, 20 Aug 1999 12:16:21 -0700 From: "David O'Brien" <obrien@NUXI.com> To: Peter Wemm <peter@netplex.com.au> 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> In-Reply-To: <19990820182100.9A7781C9F@overcee.netplex.com.au>; from Peter Wemm on Sat, Aug 21, 1999 at 02:21:00AM %2B0800 References: <19990820110114.Y76112@dragon.nuxi.com> <19990820182100.9A7781C9F@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990820121621.C76112>