Date: Sat, 21 Aug 1999 00:29:16 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: obrien@NUXI.com Cc: Peter Wemm <peter@netplex.com.au>, 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: <199908202029.AAA02133@tejblum.pp.ru> In-Reply-To: Your message of "Fri, 20 Aug 1999 12:16:21 PDT." <19990820121621.C76112@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908202029.AAA02133>