From owner-cvs-all Fri Aug 20 13:32:23 1999 Delivered-To: cvs-all@freebsd.org Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id 4787014F4B; Fri, 20 Aug 1999 13:32:07 -0700 (PDT) (envelope-from dima@tejblum.pp.ru) Received: (from uucp@localhost) by arc.hq.cti.ru (8.9.3/8.9.3) with UUCP id AAA43755; Sat, 21 Aug 1999 00:28:35 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Received: from tejblum.pp.ru (localhost [127.0.0.1]) by tejblum.pp.ru (8.9.3/8.9.3) with ESMTP id AAA02133; Sat, 21 Aug 1999 00:29:16 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Message-Id: <199908202029.AAA02133@tejblum.pp.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: obrien@NUXI.com Cc: Peter Wemm , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org From: Dmitrij Tejblum Subject: Re: cvs commit: src/include histedit.h src/lib/libedit Makefile editline.3 el.c el.h In-reply-to: Your message of "Fri, 20 Aug 1999 12:16:21 PDT." <19990820121621.C76112@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Aug 1999 00:29:16 +0400 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk "David O'Brien" wrote: > > With stuff using libedit, in /usr/src, the fix is also deterministic. If you > > With libedit in this, yes. But what about ports? Avoiding the major version bump is much more important for ports. Suppose, I have FreeBSD 3.2 and want to install a package that use libedit. I download it from the packages-stable directory. If you bumped the libedit version number, the program _will_ fail. If you didn't bump it, it might not fail. (If it fail - sight, this is progress). packages-3.2 directory is likely to have an obsolete version of the package. Upgrading FreeBSD is usually a bit more difficult than installing new package, you know. Then, imagine an ISV, whose binary-only product use libedit. If he build the product on 3.3, it will not work on 3.2. If he build it on 3.2, it will require installing a compat dist on 3.3. (Have you added libreadlibe.so.3 in a compat dist? :-) This is a big headache. The easy workaround is to link statically. I hate this idea. > > 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. [...] If the new readline is indeed backward compatible, then bumping the version number was a mistake. (If the new readline isn't backward compatible, its [GNU] maintainers made the mistake :-) > 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. Yes, I am in agreement that the second is much better. :-) > > > 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/. [...] Yes, the libc_r version bump in -current was a mistake (that happen to actually affect me). I didn't post objections at the time because I was very busy and someone else already objected. I stiil hope the vesion number can be umbumped in some way. There were precedents for this in the pre-3.0 period. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message